{"id":52344,"date":"2024-11-20T11:25:52","date_gmt":"2024-11-20T10:25:52","guid":{"rendered":"https:\/\/setterwalls.se\/?post_type=articles&p=52344"},"modified":"2024-11-26T15:33:58","modified_gmt":"2024-11-26T14:33:58","slug":"what-about-the-little-guy-the-smes-practical-guide-to-dora","status":"publish","type":"articles","link":"https:\/\/setterwalls.se\/en\/article\/what-about-the-little-guy-the-smes-practical-guide-to-dora\/","title":{"rendered":"What About the Little Guy? \u2013 the SME\u2019s Practical Guide to DORA"},"content":{"rendered":"
\n
\n
\n
\n
\n

You would be hard-pressed to find anyone in the FinTech industry who hadn\u2019t noticed the buzz around DORA. Part of the success behind DORA\u2019s 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.<\/strong><\/p>\n

Background<\/h4>\n

Regulation (EU) 2022\/2554 of the European Parliament and of the Council of 14 December 2022 on digital operational resilience for the financial sector (\u201cDORA<\/strong>\u201d), is part of the EU\u2019s 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 (\u201cICT<\/strong>\u201d) service providers in the EU.<\/p>\n

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 (\u201cSMEs<\/strong>\u201d) \u2013 which generally are more streamlined, with nimble structures typically featuring low staff headcount and limited resources \u2013 oftentimes lack a clear strategy on how to tackle compliance when faced with a vast set of requirements.<\/p>\n

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]<\/a>\u00a0This 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.<\/p>\n

Key takeaways from DORA<\/h4>\n

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.<\/p>\n

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.<\/p>\n

Although DORA is a new framework, some of the financial entities may already be familiar with the so-called EBA Guidelines.[2]<\/a>\u00a0At 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 \u2013 which have not been subject to the EBA Guidelines \u2013 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]<\/a><\/p>\n

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]<\/a><\/p>\n

The SME\u2019s \u201cstep-by-step\u201d plan<\/h4>\n

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.<\/p>\n

Step one \u2013 Find out if, and to what extent, DORA is applicable<\/em><\/strong><\/p>\n

Step one may almost come across as redundant, but it is worth having an extra look as to\u00a0if<\/em>, and\u00a0to what extent<\/em>, 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]<\/a>\u00a0(hereinafter \u201cProviders<\/strong>\u201d) 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]<\/a><\/p>\n

Under certain specific circumstances, DORA does not apply to managers of alternative investment funds. Furthermore, DORA also contains an exception whereby certain financial entities \u2013 which fall under the scope of DORA \u2013 are exempted from the \u201cfull version\u201d, 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\u00a0microenterprise<\/em>s are also subject to fewer and\/or lighter requirements under DORA.[7]<\/a><\/p>\n

Step two \u2013 Gather the team<\/em><\/strong><\/p>\n

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.<\/p>\n

Step three \u2013 Start doing a GAP analysis<\/em><\/strong><\/p>\n

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.<\/p>\n

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 \u2013 e.g. columns covering who is being assigned the specific requirement, progress, and deadlines \u2013 an overview in a format which the stakeholders should already be quite familiar with can be achieved.<\/p>\n

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]<\/a><\/p>\n

When conducting the initial GAP analysis, it is important to keep in mind that the underlying purpose \u2013 at this stage \u2013 is to simply perform a status-check over\u00a0what<\/em>\u00a0is in place<\/em>\u00a0and\u00a0what is lacking<\/em>.<\/p>\n

Step four \u2013 Map out your ICT<\/em><\/strong><\/p>\n

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.<\/p>\n

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]<\/a>\u00a0and ICT assets[10]<\/a>\u00a0supporting those functions; and (iii) their roles and dependencies in relation to ICT risk[11]<\/a>. However, several additional mapping requirements apply under Article 8, such as:<\/p>\n