MFSA DORA 2025 Authorisation Lessons: ICT Gaps Accounting Firms Must Close

The Malta Financial Services Authority has published a circular drawing on its observations from the 2025 authorisation cycle, and the message for financial firms is direct: awareness of the Digital Operational Resilience Act is rising, but the gap between documented policy and working practice remains wide. For accounting firms advising crypto clients, CFOs running digital asset operations, and any entity whose crypto accounting software infrastructure touches EU-regulated activities, the circular is a practical checklist disguised as a supervisory reflection.

What the MFSA Circular Actually Says

The Authority reviewed authorisation applications and identified common, recurring failures in how applicants demonstrate compliance with DORA, formally Regulation (EU) 2022/2554 of the European Parliament and of the Council of 14 December 2022 on digital operational resilience for the financial sector. The circular does not name individual firms. Instead it maps the landscape of where the sector is still falling short, and where it is beginning to get things right.

The Core Finding: Policy Without Practice

The central observation is that many applicants arrive with documentation in place but cannot show how those policies function under real conditions. The Authority explicitly states that digital operational resilience extends beyond the preparation of policies and documentation. Examiners want to see that resilience measures actually support the continuity, security, and reliability of business activities day to day, not just on paper submitted to a regulator.

This distinction matters enormously for firms running or advising on digital asset accounting software environments. A policy document describing how an ICT incident is escalated is not the same as a tested, functioning incident management procedure with defined roles, documented thresholds, and evidence of at least one dry run.

Four Recurring Weakness Areas

The MFSA groups its concerns around four pillars that map directly onto DORA's own structure:

• Governance arrangements: Applicants frequently lack clear board-level accountability for ICT risk. Ownership is diffuse, escalation paths are undefined, and senior management cannot demonstrate active oversight of the resilience framework rather than passive approval of a document.
• ICT risk management processes: Risk registers exist but are often static, generic, or disconnected from the applicant's actual technology stack and business model. The Authority expects registers to reflect the specific risk profile of the entity, not a templated list of generic cyber threats.
• Incident management procedures: Detection, classification, and reporting workflows are present in writing but have not been operationalised. Firms cannot demonstrate how they would identify a major ICT incident, classify its severity under DORA's criteria, or notify the MFSA within the required timeframes.
• Third-party ICT service provider oversight: This is identified as a particular pain point. Contracts with cloud providers, data vendors, and outsourced technology partners often lack the clauses DORA requires, and internal oversight of those providers is thin or entirely absent.

Where Applicants Are Getting It Right

The circular is not uniformly critical. The MFSA specifically notes that applicants generally demonstrated stronger levels of preparedness in the area of digital operational resilience testing. This is meaningful: firms appear to have invested in penetration testing, vulnerability assessments, and continuity exercises more readily than they have in the governance and contractual infrastructure that surrounds those tests.

Why Testing Alone Is Not Enough

A test result without a governance framework to act on it, escalate findings, and track remediation is limited in its regulatory value. The Authority's observation suggests that some applicants treat testing as a deliverable rather than as an input into a continuous risk management cycle. For firms whose crypto bookkeeping software or digital asset accounting software connects to multiple third-party data feeds, exchanges, or custody APIs, a penetration test of one component does not substitute for an integrated resilience framework covering the whole chain.

DORA's Scope and Why EU Crypto Firms Cannot Ignore It

DORA applies across the EU financial sector, including crypto-asset service providers authorised under MiCA. Malta is one of the most active CASP authorisation jurisdictions in the EU, which makes the MFSA's observations particularly significant as a leading indicator of what other national competent authorities are also finding. Firms that have obtained or are pursuing MiCA authorisation in Malta, or that rely on a Maltese entity for EU passporting, need to treat this circular as supervisory guidance with direct practical effect.

The MiCA Connection

MiCA does not replicate DORA but it does not sit in isolation from it either. CASPs that are also caught by DORA, because of their size, their role as significant ICT third-party providers, or because they operate within a group that includes DORA-obligated entities, face a dual compliance burden. The MFSA's observations suggest that firms applying for CASP authorisation are being assessed on their DORA readiness as part of the same authorisation process, and weaknesses in one framework will likely raise questions about the other.

This has been a pattern elsewhere in the EU. Belgium's FSMA has already taken action on unauthorised CASPs following the MiCA deadline, as covered in our piece on Belgium FSMA flags six unauthorised CASPs after MiCA deadline. The trajectory is clear: regulators across the bloc are tightening authorisation standards simultaneously across both the crypto-specific and cross-sector digital resilience frameworks.

Practical Implications for Accounting Firms and CFOs

The MFSA's circular is addressed broadly, but its operational implications vary depending on where a firm sits in the ecosystem.

For Accounting Firms Advising DORA-Obligated Clients

Advisers need to understand that DORA compliance reviews will increasingly form part of pre-authorisation due diligence, annual supervisory engagement, and potentially audit scope. The four weakness areas identified by the MFSA translate into audit and advisory work streams:

• Governance gap analysis: mapping board-level accountability for ICT risk against DORA's requirements and identifying where responsibility is unclear or unassigned.
• ICT risk register review: assessing whether the register reflects the client's actual technology architecture, including any crypto accounting software or digital asset accounting software components, rather than a generic template.
• Third-party contract audit: reviewing vendor agreements against DORA's mandatory contractual provisions, particularly for cloud-based infrastructure and outsourced data processing.
• Incident management walkthrough: facilitating a tabletop exercise to test whether the documented procedure actually works, and producing evidence that can be presented to a regulator.

For CFOs and In-House Finance Teams at Digital Asset Firms

The MFSA's finding that submissions are often not tailored to the applicant's specific business model and risk profile is a direct signal to CFOs. A generic DORA framework purchased off the shelf or copied from a larger institution's disclosure will not satisfy the Authority. The risk profile of a CASP running a token trading platform is materially different from that of a traditional payment institution, and the documentation must reflect that.

For finance teams, the third-party oversight gap is particularly acute. Digital asset operations typically rely on a web of external providers: blockchain data feeds, exchange connectivity, custody solutions, staking infrastructure, and the crypto bookkeeping software layer that sits above all of it. Each of those relationships needs a DORA-compliant contract and an ongoing oversight process. The MFSA's observations suggest this is where most firms are currently under-resourced.

The same pattern is visible in how France's AMF has approached post-MiCA supervision, detailed in our analysis of how the AMF's new supervisory role reshapes CASP licensing in France. Across EU jurisdictions, the direction of travel is toward deeper, evidence-based scrutiny rather than document-receipt compliance.

Accounting and Financial Reporting Considerations

The DORA compliance posture of a regulated entity has financial reporting implications that are easy to overlook until an incident or a supervisory finding makes them unavoidable.

Provisions and Contingent Liabilities

Where an ICT risk has been identified, documented, but not remediated, finance teams need to consider whether a provision or contingent liability disclosure is required under the applicable accounting standard. A known gap in incident management procedures is not simply an operational matter if it creates a probable obligation to the regulator or to affected counterparties following an incident. DORA-related remediation costs also need to be planned and budgeted, and material capital expenditure on ICT infrastructure upgrades may need to be disclosed in forward-looking risk disclosures.

Third-Party Contract Renegotiation Costs

Bringing existing vendor contracts into DORA compliance is not cost-free. Legal fees, contract amendment costs, and the potential need to migrate to a compliant provider where an existing vendor refuses to accept DORA-mandated terms are all financial items that the CFO function needs to own. For firms that have not yet mapped their third-party exposure, the first step is an inventory: every external ICT dependency that supports a regulated activity needs to be identified and assessed.

ICT Risk in the Internal Control Framework

DORA's requirements for ICT risk management are substantive enough that they should be reflected in a firm's internal control framework and, where applicable, in the scope of internal audit. External auditors are increasingly being asked by clients and by regulators about the robustness of ICT governance. Firms that can demonstrate a live, tested, and board-owned DORA framework will be in a materially stronger position both in supervisory interactions and in audit conversations than those presenting static documentation.

What Firms Should Do Before the Next Authorisation Window

The MFSA states that the circular is intended to support both prospective and existing licence holders in preparing for authorisation processes. That framing is important: this is not retrospective criticism of past applicants, it is forward guidance for anyone whose authorisation renewal or initial application is coming up.

The practical sequence for most firms will be: first, assess current ICT governance against each of the four weakness areas the MFSA identifies. Second, commission or conduct a gap analysis on all third-party ICT contracts. Third, run at least one documented incident management exercise and retain the evidence. Fourth, ensure the risk register is rebuilt or reviewed to reflect the firm's actual systems, including any crypto accounting software components that form part of the regulated infrastructure. Fifth, take the results to the board and document that discussion.

The Authority has been explicit that it expects submissions to be tailored. A credible DORA submission from a Maltese CASP in 2025 or 2026 will look nothing like a submission from a traditional credit institution. The business model, the technology stack, and the risk profile must drive the content.

Source: Malta Financial Services Authority

Frequently Asked Questions

What is the MFSA DORA circular about?

The Malta Financial Services Authority published a circular summarising recurring weaknesses it observed during the review of authorisation applications under the Digital Operational Resilience Act (DORA). It identifies governance, ICT risk management, incident management, and third-party oversight as the main areas where applicants are still falling short, and notes that resilience testing is the area of relative strength.

Which firms does DORA apply to?

DORA, formally Regulation (EU) 2022/2554, applies across the EU financial sector. This includes credit institutions, investment firms, payment institutions, crypto-asset service providers authorised under MiCA, and a range of other financial entities. The specific obligations and proportionality thresholds vary by entity type and size.

Does DORA affect crypto-asset service providers in Malta?

Yes. CASPs authorised under MiCA in Malta are part of the EU financial sector and fall within DORA's scope where the relevant thresholds and conditions are met. The MFSA's circular makes clear that DORA compliance is assessed as part of the authorisation process, meaning weaknesses in ICT governance or third-party oversight can affect a CASP's ability to obtain or retain its licence.

What should a CFO do in response to the MFSA circular?

CFOs at DORA-obligated firms should treat the four weakness areas the MFSA identifies as a practical checklist: ICT governance and board accountability, the specificity and currency of the ICT risk register, the operationalisation of incident management procedures, and the contractual and oversight arrangements with third-party ICT providers. Each area should be assessed against current practice, not just against existing documentation.

How does the MFSA circular relate to crypto accounting software infrastructure?

Any crypto accounting software or digital asset accounting software that forms part of a regulated firm's operational infrastructure is an ICT system for DORA purposes. If that software is hosted by a third-party provider, the contract and oversight arrangements must meet DORA's requirements. If it is operated internally, it falls within the ICT risk management and resilience testing scope that the MFSA expects firms to document and demonstrate.