Does DORA apply to SaaS vendors?

As a quick introduction, the Digital Operational Resilience Act (DORA) emerged in response to concerns that existing financial regulations did not sufficiently address ICT (Information and Communication Technology) risks. The Act harmonises and strengthens ICT risk management across the EU financial sector by imposing strict operational resilience requirements.

For me, its arrival is reminiscent of how GDPR came on to the scene. DORA is much more targeted but, much like GDPR, few people really understand it well and many companies have (and continue to) put in place reactionary solutions which ultimately cause unnecessary challenges.

So, does it apply to you?

Not by default (unless you provide regulated financial services), but if you are an ICT third-party service provider providing services - including digital services (and therefore cloud services) - to financial entities, then you need to ensure that you have a clear understanding of how the Act impacts your business.

How does it apply?

Being an ICT provider does not subject you to the totality of the Act, but it does mean that your financial sector customers will expect to impose certain obligations on you to ensure their own compliance with the Act.

More specifically, they will include a number of key contractual provisions in their contracts, typically through an addendum to your main contract, to ensure that they comply with Article 30 of the Act.

Without delving into specifics, it’s crucial to understand that Article 30 is made up of two sets of obligations. The first batch is contained in Article 30.2, applies to all ICT providers and is fairly eye-watering if you are not used to a certain level of scrutiny. At a high level, it requires the inclusion of various resilience measures (including in relation to service levels, subcontracting, security controls and business continuity) and it includes associated termination rights.

The second group is set out in Article 30.3 and applies only to those ICT providers which support critical or important functions. The additional, and much more invasive, obligations (like penetration testing and significant audit rights) will be problematic for most SaaS vendors, especially those selling an off-the-shelf solution which is subject to a rigid delivery model.

The bar for meeting this threshold is high and requires assessing whether a disruption or failure of the supported function could materially impact a financial entity’s financial performance, service continuity, or regulatory compliance.

While financial entities and ICT vendors may not always align in their assessment of what constitutes a critical or important function, vendors need to be mindful that supporting such functions increases the likelihood of being designated as a critical ICT third-party service provider (CTPP).

Such designation goes well beyond additional contractual obligations as CTPPs become subject to the oversight (under an EU oversight framework) of the Lead Overseer (a role played by the European Supervisory Authorities (ESA)) that has extensive powers which, if ignored, can lead to penalties (based on a % of world turnover).

Thankfully, the decision as to whether an ICT provider is a CTPP sits firmly with the ESA (not the customer) but accepting that you support critical or important functions is a first step towards eventually becoming a CTPP, so you should firmly resist a customer’s attempts to include Article 30.3 obligations in your contract (unless, of course, the nature of your service dictates otherwise).

As of the date of this post the ESA have yet to designate which providers qualify as being “critical”, but such designation is likely to apply only to a handful of providers and therefore not to most SaaS solutions.

So, as a SaaS vendor, what are your next steps?

If you want to sell into the financial sector in the EU, the first thing you need to do is determine how your operations stack up against the requirements set out in Article 30.2.

Once you have done that, you need to develop a DORA Addendum that you can present to customers when asked how your company “deals with DORA” - instead of being faced with the alternative of signing a customer-drafted addendum which a) is not aligned with the realities of your business and b) is likely to contain Article 30.3 obligations.

Developing a DORA addendum is a challenging task which involves striking a fine balance between providing suitable information to allow customers to show that they have complied with Article 30 and creating a set of terms with which you are able to comply. Leveraging your standard MSA is a great place to start but there’s a lot more to it than that.

Having negotiated financial service addenda of this nature with numerous banks in the EU, I am well placed to assist you with this task. If you think I can help, please don’t hesitate to reach out.