IT Suppliers' Legal Obligations

DORA is not your problem. Your European client's auditor is.

Gleb Etinzon, DORA Consultancy.
A boutique consultancy addressing complex regulatory requirements in a pragmatic way. London, UK.

You are a very serious IT supplier, with nice-looking clients' logos on your website, a marketing department that highlighted your financial-industry-aligned product or service, a bunch of technical people who created it, and, of course, an even more brilliant sales team that sold it.

DORA doesn't apply to you, but it does apply to your client.
Your European-based clients sent a DORA addendum (often titled an ICT Third-Party Risk Addendum or Digital Operational Resilience Addendum) with multiple vague legal clauses. You googled it, ran it by your legal team (if you can afford one), or used ChatGPT. All of them gave you comments, but, looking into the desperate-for-commission faces of your sales team, you decided to accept the requirements.

From a European regulator's point of view, they really don't care about your company or product; however, they are keen on ensuring broader market stability, and information technology is key to that. Apparently, there are 15,000 companies like yours, so consider yourself in a good company.

The DORA addenda you're receiving are drafted by European lawyers who are over-indexing to protect their clients. Simply signing what's put in front of you is commercially reckless, while refusing to engage is existentially reckless. You have to find the middle path — understanding what DORA actually requires of a third-party ICT provider versus what your client's lawyers are asking for on top of that, and negotiating the delta. Most firms don't know there's a delta to negotiate.

Not that you can afford not to sign it, though.

Your client's regulator will hold them accountable for your resilience posture, which means your client's procurement and legal teams will push the full weight of DORA down the contract chain onto you. The clauses will be clumsy, inconsistent, and often go beyond what the regulation actually requires.
Your company may be an ISO 27001 or SOC2 certified and has already passed the most difficult hurdle — the procurement check box. Is this sufficient? No.

The Challenge.

Let me break down what those can be.

Let's start with the definition of an ICT service provider.
“ICT services” (Article 3(21)) means digital and data services provided through ICT systems on an ongoing basis, including hardware-as-a-service and hardware support”. The definition is broad enough to include pretty much any of IT suppliers. Most financial entities struggle to correctly identify which IT suppliers support a “critical or important function (CIF)” within the business, mainly because running a proper risk assessment is not trivial activity and it requires skills. While the decision is made entirely by a financial entity, this is your first opportunity to object and work with your client to pragmatically address their concerns by evaluating their risk approach and constraints.

Ask them the following questions to validate your CIF classification:

“What specific 'Critical or Important Function' does our service support, and what was the impact assessment that led to this classification?”

Why: You want to know if they are being overly cautious (classifying everything as CIF) or if there is a specific regulatory reason.

“Is our service the sole provider for this function, or is there built-in redundancy through another ICT provider?”

Why: If you are the single point of failure, your risk profile and the client's “Exit Strategy” requirements become much more complex.

“What are the mandatory Recovery Time Objectives (RTO) and Recovery Point Objectives (RPO) defined by your business continuity policy for this CIF?”

Why: Standard “99.9% uptime” is not the same as a DORA-mandated recovery window. You need to know whether your current infrastructure meets their specific disaster-recovery needs.

If you are unsuccessful in this stage, congratulations. You have been upgraded from an IT service provider to a partner in regulatory risk. Now is an opportunity to review your historical agreement. It is likely that you already have various compliance and security-related clauses there that were sufficient in the first place. Use your second opportunity to evaluate the current state of your services vs the new DORA requirements. In many cases, your obligations will already be in place, at least on paper.

What does it mean?

Area	What you have now	What you need to do
Incident management	Notify your client about incidents within 72 hours, probably linked to your GDPR obligations.	Identification and notification without undue delay (often defined as within 4 to 24 hours of discovery, per best practices from Regulatory Technical Standards — RTS), followed by remediation without any additional cost, and proper reporting (root cause analysis).
Third-party supplier management	A vague requirement to ensure your third-party suppliers' compliance.	DORA requires the primary provider to take full responsibility for the “entire chain” of subcontractors.
Internal audit	Probably nothing.	Your internal audit scope must satisfy your client and explicitly evaluate the relevant contractual arrangements.
External Audit and Inspection Rights	Probably nothing, as you want to avoid uncompensated audit costs.	Allow Unrestricted Access: The client must have the right to inspect your physical premises (unlikely to happen, though) and digital systems. Your Evidence Provision: You must agree to provide logs, SOC2/ISO 27001 reports, and evidence of “digital operational resilience testing” upon request. TLPT (Threat-Led Penetration Testing): If your client is large enough to require TLPT (e.g., “designated significant entities”) and you are deemed as “critical,” you must participate and fully cooperate in the client's red-teaming/penetration tests. Major headache, little chance to survive.
Tools and processes for security management	Probably generic requirements for vulnerability management and penetration testing.	A weekly vulnerability scan, in addition to open source analyses, network security assessments, gap analyses, physical security reviews and penetration tests.
Continuity Planning and Testing	A vague commitment to run a Business Continuity test annually.	Your Business Continuity and your client's Business Continuity (BCP): you must maintain and annually test a BCP/DR plan that aligns with the client's recovery time objectives (RTO).
Exit Strategies	Probably nothing, or a basic commitment to provide the client's related data.	Your support with client Exit Assistance: A mandatory clause requiring the provider to assist in the “seamless transfer” of data and services to a new provider or back to the client upon termination. Termination Rights: The client gains the right to terminate the agreement immediately if you fail to comply with security standards or experience a catastrophic resilience failure.

The new requirements are reasonable and aligned with the current industry practices, so it is hard to argue against them. How to pragmatically address the new requirements is a more interesting challenge, and below are a few suggestions.

Incident Management

Effort = minimal.

Requirement:
DORA requires financial entities to establish a comprehensive framework for detecting, managing, and notifying the relevant authorities of major ICT-related incidents, using standardised classification criteria and reporting timelines.

Challenge:
To manage incidents, your organisation should be able to monitor its solution and identify events for further analysis and action. Yes, this is the boring part that nobody wants to do; you need to invest effort into your team capabilities and solution automation. The benefit of this activity goes beyond your client's requirements, so do it properly, and you can feel comfortable committing to the relevant notification requirements. Some of your clients may push for very tight notification windows, e.g., 2 hours. Well, this will be tricky, at least.

What to do:

Establish a baseline to identify what is running service without an incident.
Identify and categorise applicable incident types, and start developing playbooks to address them.
Continue to monitor and tune up the playbooks, and start automating the response.
Run a quarterly incident management test. The test will help to hone your reporting template, followed by a root cause analysis report.

Third-party management

Effort = medium.

Requirement:
DORA demands that financial entities maintain a comprehensive register of all ICT third-party arrangements and ensure contracts include specific mandatory provisions for monitoring, accessibility, and exit strategies to mitigate systemic supply chain risk.

Challenge:
DORA cares about subcontractors supporting critical or important functions. You need to identify your own ICT subcontractors in that chain and reflect them in the information register maintained by your financial-entity client. Identification is recursive: your sub-providers may themselves be ICT third-party providers for the same end function. For some material subcontractors, you may need to ask your client for permission to change them.

What to do:

For the Third-party management, start with the “Map the chain” exercise to identify your own suppliers.
Once the “Map the chain” exercise is complete, critically assess your subcontractor's capabilities and advise them early of potential new requirements from your DORA-related clients, so they can improve their processes.
You may have to make difficult decisions, but it is better now than when an issue arises that impacts your obligations to your client.
Remember: If your own sub-providers (e.g., a smaller hosting partner) cannot meet DORA standards, you may be held liable for their failures under this addendum.

Audits

Effort = medium.

Requirement:
DORA requires financial entities to conduct regular, independent audits of their ICT risk management framework and digital resilience, ensuring that findings are documented and addressed through a formal remediation process to maintain operational security.

Challenge:
Internal and external audits are a new area that most IT companies don't address at all. The reason is obvious and impolite — you don't care about it. Too bad, now you have to do this right, as this is one of the critical activities to evaluate the maturity of your processes, which shows your client that you are a serious service provider.

What to do:

You don't have to hire an internal auditor or go to one of the Big Four, even if you have extra deep pockets. This is an activity that can be outsourced to a knowledgeable contractor who will help run an annual company-wide risk assessment, develop an appropriate annual audit plan, conduct audits, and work with the relevant teams to address identified issues.
One of the audits will need to focus on your compliance obligations, effectively covering supporting processes such as incident management, security management, and similar, and can be reused as part of your other compliance obligations, such as ISO 27001.
You should evaluate if you need to charge an “Audit Support Fee” to cover the man-hours required to host the client's auditors and regulators.

Tools.

Effort = high.

Requirement:
DORA mandates that financial entities implement a comprehensive suite of security tools and policies, including automated vulnerability management, robust encryption for data at rest and in transit, and continuous monitoring to ensure the ongoing confidentiality, integrity, and availability of all ICT systems.

Challenge:
Security tools and processes are something you should do anyway. The questions are whether they are good enough and whether they meet the requirements. Vulnerability management, for example, is a high priority for clients and the industry because it is the most efficient way to reduce security risks. If you can identify vulnerabilities promptly (from both external, unauthenticated and internal, authenticated perspectives) and patch them within a reasonable timeframe, you can reduce potential intrusion risk by 30 to 65 per cent. Having those processes properly in place also reduces the chances of a ransomware attack by up to 80%.

What to do:

Create periodic scans of your solution in scope and run them initially monthly.
Evaluate the results and address the externally-accessible issues first.
Create a monthly patch management cycle.
Review and improve your Identity and Access management, initially focusing on privileged access, and conduct reviews monthly for users and service accounts.
Implement the cryptography management process, map your cryptographic assets, and start rotating them periodically.
Consider embedding a “security in depth” approach into your development and release processes.
If your client is a large financial entity subject to Threat-Led Penetration Testing (TLPT), you must determine whether your service falls within the test's scope. TLPT (Red Teaming) is expensive and intrusive. If you are in scope, you need to discuss who pays for the resources needed to support these tests.

Business Continuity Management.

Effort = high.

Requirement:
DORA requires financial entities to maintain comprehensive ICT business continuity and disaster recovery plans that include diverse backup systems, periodic stress testing, and clear communication protocols to ensure the rapid restoration of critical functions and data integrity following a major disruption.

Challenge:
Some may say that continuity management is a very subjective topic. It is really a black-and-white situation, providing a working solution when needed. Or your solution is recovered on demand, or you struggle to do this when your client needs it — your unavailability undermines your client's trust. There are no shortcuts, and your real-life testing is the only way to prove that whatever your teams put within a Disaster Recovery plan document is working, or highly likely not. Table-top exercises are not a substitute for those tests, and, regardless of solution size, not an excuse for not running real-life testing either.

Most modern solutions, deployments, and recoveries should be automated end-to-end, and it is hard to justify any manual work nowadays. The main obstacle here is your team, which didn't invest in automating processes, and a leadership that never demanded their optimisation. When you invest in proper continuity, you can fully address your obligations, and providing a decent-looking report to your clients will help reduce related friction and manage their expectations.

What to do:

You need to agree on the relevant RTO/RPO objectives, taking into account your solution architecture and team capabilities.
Some clients won't appreciate the effort involved in testing on an alternative cloud provider — e.g. 'Can you test your solution migration in Azure instead of AWS?' Challenge them.
Create a set of realistic scenarios that could affect the delivery of your solution, and provide them to your client with explanations of how you will address them.
Ask relevant teams to develop automation scripts to deploy their parts from scratch. Once those are working, create an orchestration layer that links them all.
Run tests, run tests again, and again — as many times as necessary to ensure the performance and quality of your process.
Add a reporting layer and share the results with your client.

Exit strategy

Effort = high.

Requirement:
DORA requires financial entities to develop comprehensive ICT exit strategies to ensure the seamless transition of critical functions to alternative providers or in-house systems during contract termination, without disrupting services or compromising data integrity.

Challenge:
The exit strategy, inconvenient or unrelated to you, as it may be, is a material differentiator between you and your competitors (who you are not afraid of, but still respect). Your client chose your solution because of you, your team and an internal gut feeling that you will not screw them over. Therefore, do not be afraid to support your client in this area. The DORA requirements for the use of ICT services supporting critical or important functions provided by ICT third-party service providers shall include a documented exit plan for each ICT contractual arrangement, and this is the main reason why you see the requirement as a legal clause.
This is not because your client wants to leave you. The financial entity shall ensure that the exit plan is realistic, feasible, based on plausible scenarios and reasonable assumptions and shall have a planned implementation schedule compatible with the exit and termination terms established in the relevant contractual arrangements. As a service provider, you should support your client with periodic review and testing, taking into account unforeseen and persistent service interruptions, inappropriate or failed service delivery or the unexpected termination of a relevant contractual arrangement (remember your third-party dependencies?).
After all, you want to build a long-term relationship with your client, and nobody expects to stress exit any time soon, but providing your client with the comfort that they have working options is worth the extra steps here.

What to do:

If you run a multi-tenant solution, consider a single-tenant deployment for this particular client. While you may lose efficiency or cost optimisation, or pick up a new operational headache, the single-tenant setup is ready for direct handover to your client's escrow agent — which simplifies their exit strategy considerably. If they ever need to invoke it, they'll have a fully functional solution run by the escrow agent while they figure out how to migrate to another service provider.
If the single-tenant solution is too ambitious, you can offer them a source-code escrow arrangement for your solution, supported by the client's specific data. In this scenario, the client may experience some downtime while invoking the escrow, but it still provides a gap solution. Your client will probably overestimate their capabilities, but it is their risk decision here.
The escrow agent/agreement is to protect your IP and may reduce the ongoing impact/trigger event on your teams. Do not confuse this with your Business Continuity obligations.
You need to define the “Transition Period” and ensure you are paid for the effort of handing over data and configurations.

The additional client's requirements present a great business opportunity to upsell the higher-level service. Most clients are reasonable; they realise that additional requirements cost time and money, and they are ready to pay for them, which allows you to adjust your pricing and Service Level Agreements to match the actual risk you are inheriting.

What next?

Once you have agreed on those legal clauses and respective controls, the first part is over and the real fun starts.

Doing security right is really hard; most of the work is nearly invisible to the stakeholders, who don't see it as a business value anyway.

You need to create:

Pragmatic implementation plan, but it must be completed within the next 6–12 months, as your client will feel uncomfortable.
Internal review process to ensure your teams understand the legal implications of the requirements and incorporate them into their activities.
Meaningful reporting to provide evidence of your compliance with relevant clauses, highlight any discrepancies and an action plan to address them.

You should be ready for a periodic visit from a designated external auditor acting on behalf of your client. Typically, those auditors are relatively junior and may have little experience in IT risk management, in general, and with your solution challenges in particular. They will have a ridiculously long, unrelated questionnaire that will likely need to be explained line by line. This is your opportunity to adjust it in accordance with the updated legal requirements and to produce the required documentation/evidence to support your compliance obligations. Patience is the key here, and a good grasp of DORA requirements will also be beneficial.

If your company is big enough to force your customers to accept your Terms and Conditions, where your lawyers elegantly shift any responsibility onto them, you are not safe either. AI services can cross-check the DORA requirements with your Terms and Conditions in seconds, highlighting non-compliant clauses, which will trigger a very unpleasant conversation with your client.

Why do you want to do all of the above?
Firms treating the addendum as a signature exercise are accepting unbounded liability they haven't priced. Firms treating it as a negotiation are buying real protection — and, as a side effect, genuinely better operational resilience.

For help with DORA challenges above, as well as others, please reach out to the team.

Ready to discuss your DORA compliance challenges?

Our team of experienced consultants is here to help.

Get in Touch