What About the Little Guy? – the SME’s Practical Guide to DORA

You would be hard-pressed to find anyone in the FinTech industry who hadn’t noticed the buzz around DORA. Part of the success behind DORA’s awareness campaign can probably be ascribed to the ever-increasing number of cybersecurity incidents which have sent shockwaves throughout the industry. One can only speculate about just how many further incidents have occurred but which have never surfaced. Although cybersecurity has been prioritised by legacy enterprises over the last couple of years, many smaller businesses now struggle to fulfil the requirements set by DORA. If this sounds all too familiar, then this guide is designed for you.

Background

Regulation (EU) 2022/2554 of the European Parliament and of the Council of 14 December 2022 on digital operational resilience for the financial sector (“DORA”), is part of the EU’s Digital Decade strategy. The Digital Decade strategy covers many important subjects, varying from AI to cybersecurity, where DORA makes out the blueprint for cybersecurity within the financial sector and is expected to affect more than 22,000 financial entities and information and communication technology (“ICT”) service providers in the EU.

DORA entered into force on 16 January 2023 but will not apply until 17 January 2025, effectively giving the entities affected by the regulation two years in order to comply. However, the cybersecurity trend has existed within legacy enterprises, which typically are made up of larger banks, since long before 2023. Now, we see that such legacy enterprises already have come a long way in their DORA compliance. In contrast to this, a trend can be spotted where small and medium-sized enterprises (“SMEs”) – which generally are more streamlined, with nimble structures typically featuring low staff headcount and limited resources – oftentimes lack a clear strategy on how to tackle compliance when faced with a vast set of requirements.

This practical outcome, where legacy enterprises are able to comply, but SMEs have a hard time keeping up, has long been anticipated and is in line with criticism typically levied towards DORA. Regardless of whether such criticism is justified or not, the fact remains that SMEs must comply with the requirements imposed by DORA, in the same way that legacy enterprises must comply.[1] This raises the fundamental question; how does an SME get started? In this article, we will explain the key takeaways from DORA and provide a plan as to how to get started, which is specifically tailored for an SME audience. The guide can also be used by service providers, effectively giving insights as to how DORA will affect their respective businesses.

Key takeaways from DORA

In essence, DORA can be summarised into the following five pillars, each of which vary significantly in their respective requirements: (1) ICT risk management framework; (2) Management and reporting of ICT-related incidents; (3) Digital operational resilience testing; (4) Management of ICT third-party risks; and (5) Information exchange arrangements.

The DORA framework contains both practical and administrative elements. Some of the more practical elements involve the establishment of backup systems, mechanisms to promptly detect anomalous activities, and the implementation of a digital operational resilience testing programme. The more administrative elements include the drafting and regular review of a potentially quite extensive set of documentation.

Although DORA is a new framework, some of the financial entities may already be familiar with the so-called EBA Guidelines.[2] At a first glance, the frameworks share several similarities, meaning that the entity, in practice, will not have to start from scratch. However, this also means that many SMEs – which have not been subject to the EBA Guidelines – may again find themselves working uphill with little to no prior experience with similar frameworks, such as the EBA Guidelines. Here, some words of comfort for the SMEs which have to start from scratch, is that DORA covers several additional, and sometimes new, aspects which go even further than the EBA Guidelines.[3]

When navigating DORA, it is important to remember that Article 4 contains a proportionality principle which states that the size, overall risk profile, and the nature, scale and complexity of the services, activities and operations shall be considered in various sections of DORA. Basically, this means that the competent authorities will likely not expect the same level of results from an SME as they would from a legacy enterprise. Finally, it should also be mentioned that some articles in DORA contain specific exceptions for financial entities meeting the definition of a microenterprise.[4]

The SME’s “step-by-step” plan

There are several different ways and various strategies to deploy, as to how to take on the requirements imposed by DORA. In the following, we will provide one way on how to efficiently establish a foothold, and also give you some key insights along the way.

Step one – Find out if, and to what extent, DORA is applicable

Step one may almost come across as redundant, but it is worth having an extra look as to if, and to what extent, DORA is in fact applicable to your company. In Article 2(1), a list with over 20 different entities falling under the scope of DORA can be found. Here, it should be noted that ICT third-party service providers[5] (hereinafter “Providers”) are not subject to the same requirements under DORA as a financial entity, meaning that DORA will only have an indirect effect on such Providers. This indirect effect will mainly occur through the contractual arrangements between the Provider and the financial entity.[6]

Under certain specific circumstances, DORA does not apply to managers of alternative investment funds. Furthermore, DORA also contains an exception whereby certain financial entities – which fall under the scope of DORA – are exempted from the “full version”, meaning that such entities can enjoy a lighter and more agile version of DORA. With this being said, the exceptions are both few and quite narrow, meaning that many financial entities are likely to be subject to the full and complete version of DORA. Finally, so called microenterprises are also subject to fewer and/or lighter requirements under DORA.[7]

Step two – Gather the team

In practice, DORA will involve many different areas and functions in your company, making it impossible for only a selected few individuals to tackle the challenge themselves. Considering this, it is crucial to gather a broad team with varying expertise in order to achieve all of the requirements under DORA. Naturally, many of the requirements will involve stakeholders within the security field, which is precisely why a few extra sets of hands are recommended in order to avoid an unnecessarily high burden for a few individuals, as well as to avoid the creation of any avoidable bottlenecks in the project.

Step three – Start doing a GAP analysis

Once the team is set, it is time to take the first steps towards compliance. Here, the financial entity may choose several different routes in order to reach compliance, where one quite straightforward way is to start with a GAP analysis.

If the financial entity chooses to start with this approach, the GAP analysis should contain all of the specific requirements under DORA, where mapping out such requirements can be a daunting and very time-consuming task. However, mapping out the requirements is essential in order to avoid any requirements falling between the cracks. To note also that the exercise itself also provides valuable insights in regards to what is to be expected, and which functions, documents and routines are already in place (and which are not). In addition to the GAP analysis having a quality control function, it can also have the dual purpose of being a working document. By adding supplementary columns – e.g. columns covering who is being assigned the specific requirement, progress, and deadlines – an overview in a format which the stakeholders should already be quite familiar with can be achieved.

After the GAP analysis document has been drafted, each team member should be assigned with a specific set of tasks. The stakeholder should then proceed with mapping out which documentation, procedures and similar are already in place, or if additional work is required. Most likely, the result of the GAP analysis will probably differ across various financial entities, whereby some may find that they have certain necessary documentation and routines already in place, whereas others may find themselves a little bit further behind.[8]

When conducting the initial GAP analysis, it is important to keep in mind that the underlying purpose – at this stage – is to simply perform a status-check over what is in place and what is lacking.

Step four – Map out your ICT

In parallel with the GAP analysis, you should also start with the mapping of your existing ICT. The mapping of the ICT is, again, a potentially daunting task which will be time-consuming and require input from large parts of the organisation. Some other difficulties regarding the mapping are that it is spread out across DORA.

One extensive Article covering such mapping requirements is Article 8. Under this Article, a financial entity shall for example identify, classify, and document all (i) ICT supported business functions, roles and responsibilities; (ii) the information assets[9] and ICT assets[10] supporting those functions; and (iii) their roles and dependencies in relation to ICT risk[11]. However, several additional mapping requirements apply under Article 8, such as:

• cyber threats[12] and ICT vulnerabilities[13];
• network resources and hardware equipment (including those on remote sites) and the mapping of those considered critical;
• the configuration of the information assets and ICT assets and their links and interdependencies;
• processes that are dependent on Providers and interconnections with Providers that provide services that support critical or important functions.

In contrast to Article 8, which covers a very broad angle, Article 28(3) instead covers the requirement of a register of information in relation to all contractual arrangements on the use of ICT services from Providers, bearing some resemblance with the registers under GDPR.

Step five – Start with the low-hanging (and important) fruit

By this stage, you should have gained a strategic overview and already be well on your way forward. As with every project, it is important to keep moving forward and to not get too tied up in the starting pits. Here, an effective strategy could be to start with the low-hanging fruit and trust your instincts. If you already know some of the pressure points in your company’s DORA compliance, then trusting your instincts with those specific problems could be a good starting point. Afterall, you know the strengths and weaknesses of your company best.

Step six – Start re-negotiating the ICT agreements

As stated earlier, the “DORA-effect” will inevitably spill over to the Providers, having an indirect effect on the Providers.

As for now, most legacy enterprises have started negotiating their respective agreements with the Providers, but more financial entities are expected to start doing so during the upcoming months. In order to position yourself at the front of the queue, now is a good idea to be proactive and reach out to your Provider.

The process between the financial entity and the Provider can vary and be handled differently. Many Providers will likely have their own template covering the requirements under DORA. This is due to the fact that Providers will most likely have to re-negotiate a large number of agreements, making bespoke agreements in different templates (or accepting the financial entity’s own template) which is somewhat of an administrative impossibility.

If you are not in a position to insist upon having your own template, it is especially important that you make sure that the Provider’s template contains all of the key contractual provisions outlined in DORA.[14]

As an ending note regarding the agreements, financial entities may, among other requirements, only enter into contractual arrangements with Providers that comply with appropriate information security standards, with the bar set even higher if the arrangement is subject to “critical or important functions”. A good indicator as to whether the Provider fulfills such requirements could be that the Provider holds an ISO 270001 certification, but other factors are relevant too. Keep in mind that you are ultimately responsible for complying with all of the requirements under DORA, and not the Provider. As a consequence, it important that you properly evaluate not only the ICT agreement with the Provider, but also the Provider itself.

Ending notes

At a first glance, DORA compliance will most likely come across as a daunting task with its vast set of requirements involving many different functions, and where there are few available templates for compliance at this stage.

Here, our best advice going forward is to take a look at the bigger picture, what is important? The answer probably lies in the name of the regulation, digital operational resilience for the financial sector. The regulations concern identifying exposure, risk and deficiencies, and then working to resolve these issues, and to improve overall resilience; or as stated in the preamble, “observing basic cyber hygiene”.[15] Once the GAP analysis and mapping of ICT has been conducted, the initial haze often lifts.

[1] Please note that some financial entities are exempted or subject to a lighter version of DORA, see Step one – Find out if, and to what extent, DORA is applicable.

[2] EBA Guidelines on ICT risk and security risk management EBA/GL/2019/04.

[3] This is especially apparent when comparing the sheer number of pages, where the EBA Guidelines makes up for 29 pages, compared to DORA’s 79 pages.

[4] “Microenterprise” means a financial entity, other than a trading venue, a central counterparty, a trade repository or a central securities depository, which employs fewer than 10 persons and has an annual turnover and/or annual balance sheet total that does not exceed EUR 2 million, DORA, Article 3, point (60).

[5] Where an ICT third-party service provider is “an undertaking providing ICT services”, and ICT services means “digital and data services provided through ICT systems to one or more internal or external users on an ongoing basis, including hardware as a service and hardware services which includes the provision of technical support via software or firmware updates by the hardware provider, excluding traditional analogue telephone services, DORA, Article 3, points (19) and (21).

[6] It should be noted that a limited number of Providers will also be classified as critical Providers, meaning that the critical Provider, to a certain extent, will be subject to some requirements under DORA.

[7] According to Article 3(60) DORA, a microenterprise means a “financial entity, other than a trading venue, a central counterparty, a trade repository or a central securities depository, which employs fewer than 10 persons and has an annual turnover and/or annual balance sheet total that does not exceed EUR 2 million”.

[8] By way of example, a financial entity which has been subject to the EBA Guidelines should, in theory, already have certain documentation and procedures in place.

[9] “Information asset” means a collection of information, either tangible or intangible, that is worth protecting, DORA, Article 3, point (6).

[10] “ICT asset” means a software or hardware asset in the network and information systems used by the financial entity, DORA, Article 3, point (7).

[11] “ICT risk” means any reasonably identifiable circumstance in relation to the use of network and information systems which, if materialised, may compromise the security of the network and information systems, of any technology dependent tool or process, of operations and processes, or of the provision of services by producing adverse effects in the digital or physical environment, DORA, Article 3, point (5).

[12] “Cyber threat” means any potential circumstance, event or action that could damage, disrupt or otherwise adversely impact network and information systems, the users of such systems and other persons, Regulation (EU) 2019/881, Article 2, point (8).

[13] ”Vulnerability” means a weakness, susceptibility or flaw of an asset, system, process or control that can be exploited, DORA, Article 2, point (16).

[14] The key contractual provisions can be found in DORA, Article 30, where Recital (71) and (72) offers a summary.

[15] DORA, Recital 13.