MFSA’s ICT and Security Risk Management Framework: What Your Tech Function Must Demonstrate

A reading of what MFSA’s ICT and Security Risk Management Framework actually demands of a Maltese-licensed firm’s technology function — written for the people who have to demonstrate it on inspection.

The MFSA’s ICT and Security Risk Management Framework — implemented through Banking Rule BR/14 for credit institutions and equivalent provisions in the Investment Services Rules, Insurance Rules, and other rulebooks — is the principal document the Malta Financial Services Authority uses to assess how a licensed firm manages technology and security risk. Since DORA came into application in January 2025, the framework sits alongside DORA rather than being replaced by it: the substantive expectations have converged, but the MFSA reads its own rulebook on its own terms.

This is a reading of what the framework substantively requires, where MFSA inspections focus, and what changes once DORA is laid over the top.

Where the framework sits

MFSA’s ICT and Security Risk Management Framework is grounded in the European Banking Authority’s Guidelines on ICT and security risk management (EBA/GL/2019/04), adapted for Malta and incorporated into the relevant rulebook by sector. The substantive provisions are similar across rulebooks:

• Banks — Banking Rule BR/14 sets out ICT and security risk management requirements.
• Investment services firms — equivalent provisions in the Investment Services Rules.
• Payment institutions and EMIs — under the Financial Institutions Rules.
• Insurance undertakings — under the Insurance Rules, with EIOPA-aligned ICT risk requirements.
• CASPs — primarily through MiCA Article 68 and DORA, but with MFSA-specific supervisory expectations layered on.

Across all of them, the framework breaks the technology function’s obligations into seven domains.

Who this is for

• The CTO or CIO at an MFSA-licensed firm preparing for an MFSA inspection or thematic review.
• The compliance officer at a Maltese subsidiary of an international group, mapping group ICT policies to MFSA’s specific expectations.
• The board member at a licensed firm whose committee has been asked to approve the ICT framework and wants to understand what they are signing off.

The seven domains

1. Governance and strategy. Board-level ownership, an ICT strategy aligned with business strategy, defined roles and responsibilities, and clear three-lines-of-defence arrangements. A board that has not seen and approved the ICT strategy fails on inspection.

2. ICT risk management framework. A documented framework — risk taxonomy, identification, assessment, treatment, monitoring, reporting. ICT risk treated as a distinct discipline, not a sub-component of operational risk. Annual review cycle. Risk appetite expressed in terms the technology function can act on.

3. Information security. The largest single domain. Network security, endpoint security, application security, physical security, cryptographic controls, access management, and security monitoring. Each with documented policies and operational evidence.

4. ICT operations management. Asset management, capacity management, performance management, incident management, problem management, vulnerability management. The operational disciplines that keep the systems running.

5. ICT project and change management. Project governance, change management procedures, testing requirements, release management, configuration management. The disciplines that govern how the technology estate evolves.

6. Business continuity management. Business impact analysis, recovery objectives, business continuity plans, disaster recovery arrangements, tested at appropriate intervals. The MFSA expects annual testing for material services, with documented exercise reports.

7. ICT outsourcing. Outsourcing policy, risk-based oversight, contracts containing required provisions (audit rights, exit, sub-outsourcing, data location, security), and ongoing monitoring. For Maltese firms — small market, concentrated vendor pool — this is the domain that requires most attention.

Where MFSA inspections focus

From engagement patterns visible across MFSA’s recent thematic reviews and inspection findings:

Outsourcing concentration. Malta is a small market with a small vendor pool. MFSA scrutinises concentration risk — multiple firms relying on the same managed service provider, the same custody sub-provider, the same KYC vendor. Concentration mitigations are expected to be documented at the level of the individual relationship, not just stated at policy level.

Documentation versus operation. A policy exists. Does the operational evidence match it? MFSA inspectors increasingly walk through specific scenarios — a recent incident, a recent change, a recent supplier onboarding — and compare what the policy says with what actually happened. Discrepancies are findings.

Cyber capability proportional to size. A small firm is not expected to maintain a 24/7 SOC. But it is expected to have a cyber capability proportionate to its risk profile — monitoring it has chosen, detection capabilities, incident response playbooks. Firms that have outsourced their entire cyber capability to a third party without retaining oversight capability are flagged.

Business continuity that has been tested. An untested BCP is not a BCP. MFSA expects annual exercise evidence for material services, with documented lessons learned and remediation.

The DORA overlay

From 17 January 2025, DORA applies directly to most Maltese financial entities — and MFSA is the competent authority for DORA in Malta. The MFSA framework and DORA cover much of the same ground but differ in detail. The substantive answer for most firms is to treat the combined regime as one:

• DORA Article 6 ICT risk management framework satisfies most of MFSA’s governance and risk management domains.
• DORA Articles 28-30 on ICT third-party risk are more prescriptive than MFSA’s outsourcing requirements and become the controlling standard.
• DORA Article 17 incident reporting standardises what was previously a fragmented sectoral approach.
• DORA Chapter IV testing requirements layer onto the MFSA’s existing expectations.

A firm that has built to DORA properly will satisfy MFSA’s framework. A firm that has built to MFSA’s framework alone is exposed where DORA goes further.

What good looks like

For an MFSA inspection, the technology function in a defensible position has:

• A documented ICT and security risk framework approved by the board, covering the seven domains.
• An ICT risk register reflecting the firm’s actual risk profile.
• Information security policies with operational evidence — recent SIEM logs, vulnerability scan results, access reviews.
• An outsourcing register with risk classification, contracts, and oversight reports for each material provider.
• A tested business continuity plan with current exercise reports.
• Evidence of board engagement — minutes, decisions, periodic reporting.
• Alignment with DORA’s requirements where they go beyond MFSA’s framework.

How we engage with this

We read MFSA ICT frameworks. As part of a Technology Control Review scoped to BR/14 or its equivalent, we identify gaps between current state and what MFSA and DORA together expect, with specific recommendations the board can act on.

We do not implement controls. We do not run penetration tests. We do not sell GRC software. We read what is there, identify what is missing, and write it down for the people who have to decide what to do about it.

Pricing is published at /pricing/. If your firm is preparing for an MFSA inspection or a DORA supervisory engagement, the place to start is a conversation.

Sixteen Pillars is a technology governance consultancy based in Cyprus. Engagements run remote across the EU, UK, and Middle East, with on-site time where the engagement requires it.