Vendor Risk Management for Financial Institutions
Third party vendor risk management for financial institutions is not optional. DORA mandates it. NIS2 reinforces it. Financial institutions operating across the EU must identify, assess, and continuously monitor every third party relationship, from cloud providers to payment processors.
Trusted by 100+ organisations across Europe
DORA NIS2 
EBA Guidelines 
ICT TPRM Key Takeaways
- DORA Article 28 requires financial institutions to maintain a complete, auditable register of all ICT third party service providers from 17 January 2025.
- DORA Article 30 mandates specific contractual provisions in every ICT third party contract, including audit rights, sub-outsourcing disclosures, and termination rights.
- NIS2 Article 21 extends supply chain risk obligations beyond ICT suppliers to any third party that could affect network and information system security.
- Critical ICT third party service providers designated under DORA Article 31 are subject to direct oversight by European Supervisory Authorities.
- Exit strategies and concentration risk assessments are mandatory under DORA, not optional programme enhancements.
- Audit-ready evidence requires documented assessment outputs, risk rating rationale, escalation trails, and remediation tracking linked to specific vendors.
- Automation is operationally necessary for institutions managing large vendor portfolios under DORA and NIS2 obligations.
Last updated January 2025.
Financial Vendor Risk Requires Auditable Evidence
A complete, documented, auditable vendor risk programme
- DORA Article 28: complete register of all contractual arrangements with ICT third party service providers
- DORA Article 30: mandatory contract clauses covering service descriptions, data location, sub-outsourcing, audit rights, and termination rights
- NIS2 Article 21: supply chain security measures for third parties affecting network and information system security
- EBA Guidelines: ICT third party risk policies, due diligence before onboarding, and ongoing monitoring
- Documented evidence available on demand for national competent authorities
Penalty exposure: Failure to demonstrate compliance carries fines of up to €10 million or 2% of global annual turnover under NIS2, and potentially higher penalties under DORA’s sector-specific provisions.
Fragmented lists, manual reviews, and evidence gaps
- Multiple fragmented lists across procurement, IT, and legal teams
- Vendor contracts missing DORA Article 30 provisions
- No operational process behind EBA-compliant documentation
- Limited visibility into sub-outsourcing and fourth party risk
- Manual monitoring that cannot scale across hundreds of vendor relationships
- Committee minutes without assessment outputs, risk rationale, or remediation tracking
The audit reality: Regulators want the assessment output, the risk rating rationale, the escalation trail, and the remediation tracking, linked to a specific vendor and point in time.
Everything Financial Institutions Need for Vendor Risk
Complete ICT Third Party Register
DORA Article 28 requires a complete register of all contractual arrangements with ICT third party service providers. StartComply gives financial institutions one live record that reflects vendor relationships, contractual terms, risk ratings, and monitoring outcomes.
- Centralised inventory for ICT providers, cloud services, payment processors, and critical suppliers
- Structured classification by critical, important, and standard tiers
- Live updates for contractual terms, risk ratings, and monitoring results
- Audit-ready register built for regulatory reporting
Automated Vendor Onboarding Assessments
The onboarding assessment must include scoring, risk-rating, escalation for high-risk findings, and documented sign-off by an accountable owner. StartComply automates the workflow so assessments are repeatable, evidenced, and mapped to DORA, NIS2, and internal risk appetite.
- Questionnaires distributed automatically per vendor tier
- Responses scored against configurable risk criteria
- Risks flagged for review and escalation
- Evidence stored in a centralised audit trail
Continuous Monitoring and Auto-Escalation
Onboarding is not the end of the process. DORA and EBA guidelines require ongoing monitoring of third party arrangements, especially for critical ICT third parties.
- Triggered reviews after incidents, sub-outsourcing changes, or financial deterioration
- Monitoring of performance against contractual SLAs
- Auto-escalation workflows for material findings
- Full audit trail of actions taken and outcomes documented
StartComply vs. The Alternatives
Not all third party vendor risk management approaches produce the evidence DORA, NIS2, and EBA-aligned inspections require.
StartComply was built for European organisations that need operational vendor risk evidence, not another layer of disconnected paperwork.
What DORA and NIS2 Actually Require from Financial Institutions
DORA (the Digital Operational Resilience Act) became directly applicable across EU member states from 17 January 2025. It applies to banks, investment firms, insurance undertakings, payment institutions, crypto-asset service providers, and a broad range of other financial entities. DORA Article 28 requires financial entities to maintain a complete register of all contractual arrangements with ICT third party service providers. This is not a suggestion. It is a legal obligation, enforceable by national competent authorities.
Beyond the register, DORA Article 30 specifies mandatory contractual provisions that must appear in every ICT third party contract. These include: full service descriptions, data location disclosures, sub-outsourcing chains, audit rights, and termination rights. If your current vendor contracts do not contain these provisions, you are already non-compliant. Remediation requires a systematic contract review programme, not a one-off legal exercise.
NIS2 Directive Article 21 adds another layer. Essential and important entities, which includes many financial institutions, must implement measures to manage risks in their supply chains. This explicitly covers the security of network and information systems used by third parties that deliver services to the institution. NIS2 does not define a specific assessment methodology, but regulators expect documented, risk-based processes with evidence of continuous monitoring.
The EBA Guidelines on ICT and security risk management (EBA/GL/2019/04) predate DORA but remain relevant for institutions within EBA scope. They require formal ICT third party risk policies, due diligence processes before onboarding, and ongoing monitoring of critical third party arrangements. Many institutions have EBA-compliant documentation on paper but no operational process to back it up.
Critical vs Non-Critical ICT Third Parties Under DORA
DORA introduces a tiered classification system. Not all third party vendors carry the same regulatory weight. Critical ICT third party service providers (CTPPs) are subject to direct oversight by European Supervisory Authorities, including the EBA, ESMA, and EIOPA. These are the hyperscalers, major cloud providers, and systemic infrastructure vendors that serve multiple financial institutions simultaneously.
For financial institutions, the classification of each vendor as critical or non-critical must be documented and defensible. DORA Article 31 sets out the criteria for designation. Even if a vendor is not formally designated as a CTPP, your institution still bears the obligation to assess concentration risk where multiple critical functions depend on the same provider. This is an operational mapping exercise, not a legal formality.
Sub-Outsourcing and Fourth Party Risk
DORA and the EBA Guidelines both require visibility into sub-outsourcing arrangements. When your cloud vendor subcontracts infrastructure to another provider, that provider becomes a fourth party risk to your institution. Most financial institutions have limited visibility here. Fourth party risk management requires contractual rights to receive sub-outsourcing notifications and the operational processes to act on them.
This is where most vendor risk programmes break down. The contract includes the right clause, but nobody monitors for sub-outsourcing changes. A vendor quietly migrates to a new data centre in a non-approved jurisdiction, and the institution has no idea. Regulators view this as a control failure, not an oversight. Building visibility into fourth party arrangements is a core component of any credible vendor risk management framework for financial institutions. See our guide to fourth party risk management for a detailed breakdown.
Regulators audit the evidence, not the intention. Spreadsheets and shared drives do not constitute a defensible vendor risk programme for financial institutions.
The Vendor Risk Management Lifecycle in Financial Services
Risk classification determines assessment depth DORA Art. 28
Pre-onboarding due diligence must be risk-proportionate. A critical ICT provider supporting payment processing requires a fundamentally different assessment than a stationery supplier. Risk classification determines the depth of assessment required, and that classification must itself be documented and defensible.
Run vendor onboarding assessments DORA / NIS2
The onboarding assessment is where most institutions send a questionnaire and then do nothing with the responses. That is not a control. The vendor risk management questionnaire must be mapped to the specific obligations under DORA, NIS2, and your internal risk appetite.
Continuously review critical ICT third parties EBA ongoing monitoring
Onboarding is not the end of the process. DORA and EBA guidelines both require ongoing monitoring of third party arrangements. Continuous monitoring is mandatory for critical ICT third parties, covering changes in financial condition, security incidents, sub-outsourcing changes, and performance against contractual SLAs.
Document exit and concentration risk DORA Art. 28
DORA Article 28 explicitly requires exit strategies for ICT third party service providers. Exit planning must be documented before the contract is signed, not after problems emerge. Concentration risk must be assessed where multiple critical functions depend on a single vendor.
Connect risk decisions to audit trail Audit-ready
Assessments should cover cybersecurity posture, financial stability, data protection compliance, operational resilience, and business continuity capabilities. Every assessment, risk rating, escalation, review, and remediation action should be linked to a specific vendor and point in time.
Client Testimonials
“We evaluated enterprise platforms costing 10x more. StartComply does what we need at a price that makes sense.”Elena Kowalski
“Finally, a compliance tool that understands European regulations. StartComply got us audit-ready in weeks, not months.”Maria Papadopoulou
“The AI policy engine alone saved us hundreds of hours. And the third-party risk management is exactly what DORA requires.”Thomas Müller
Frequently Asked Questions About Third Party Vendor Risk Management for Financial Institutions
What does DORA require for third party vendor risk management in financial institutions?
DORA requires financial institutions to maintain a complete register of all ICT third party service providers under Article 28, include specific contractual provisions in ICT third party contracts under Article 30, implement pre-onboarding due diligence, conduct ongoing monitoring, and document exit strategies. Critical ICT third party service providers face direct oversight by European Supervisory Authorities. These obligations became applicable from 17 January 2025 and are enforceable by national competent authorities.
How is DORA vendor risk management different from NIS2 supply chain requirements?
DORA applies exclusively to financial sector entities and is more prescriptive. It specifies mandatory contract clauses, a formal third party register, and a tiered classification system for ICT providers, including direct regulatory oversight for designated critical providers. NIS2 applies more broadly to essential and important entities across multiple sectors and requires risk-based supply chain security measures without prescribing specific contract terms. Financial institutions subject to DORA must comply with both regimes, which are complementary rather than contradictory.
What is a critical ICT third party service provider under DORA?
A critical ICT third party service provider (CTPP) is one formally designated by a European Supervisory Authority under DORA Article 31. Designation criteria include the systemic impact the provider would have if it failed, its market share across EU financial institutions, and its substitutability. Major cloud providers and systemic infrastructure vendors are likely candidates. Even before formal designation, financial institutions must assess concentration risk where multiple critical functions depend on a single vendor.
How often should financial institutions reassess third party vendors under DORA?
DORA and EBA guidelines require ongoing monitoring with periodic reassessment at a frequency proportionate to the vendor’s risk classification. For critical ICT third party providers, annual reassessment is a minimum, supplemented by triggered reviews following material events such as security incidents, sub-outsourcing changes, or financial deterioration. Lower-risk vendors may be assessed on a less frequent cycle, but the rationale for that frequency must be documented and defensible to regulators.
What happens if a financial institution fails to comply with DORA vendor risk obligations?
National competent authorities can impose supervisory measures including requirements to remediate identified gaps, restrictions on activities, and financial penalties. DORA penalties vary by member state implementation but regulators have broad powers to impose measures proportionate to the severity of the breach. Additionally, NIS2 non-compliance carries fines of up to €10 million or 2% of global annual turnover for essential entities. Reputational damage and supervisory scrutiny are additional consequences that materially affect ongoing regulatory relationships.
Do DORA vendor risk requirements apply to non-EU financial institutions operating in Europe?
DORA applies to financial entities operating within the EU, regardless of where their parent company is headquartered. A US or UK bank with EU operations, branches, or regulated subsidiaries must comply with DORA for those EU entities. The regulation does not apply extraterritorially to purely non-EU operations, but any ICT third party service supporting EU-regulated activities falls within scope. Institutions with cross-border structures should map DORA obligations to each regulated entity individually.
Build an Audit-Ready Vendor Risk Programme
Which Financial Institutions Need Vendor Risk Management?
DORA applies to banks, investment firms, insurance undertakings, payment institutions, crypto-asset service providers, and a broad range of other financial entities. NIS2 adds supply chain security obligations for essential and important entities, including many financial institutions, where third parties can affect network and information system security.
Institutions with cross-border structures should map DORA obligations to each regulated entity individually, especially where ICT third party services support EU-regulated activities.
DORA Vendor Risk Timeline for Financial Institutions
The EBA Guidelines on ICT and security risk management already required formal ICT third party risk policies, due diligence before onboarding, and ongoing monitoring of critical third party arrangements.
DORA became directly applicable across EU member states. Financial entities became legally required to maintain a complete ICT third party register and meet DORA’s third party risk obligations.
Financial institutions must maintain a complete register of all contractual arrangements with ICT third party service providers and document exit strategies.
ICT third party contracts must include mandatory provisions covering service descriptions, data location, sub-outsourcing, audit rights, and termination rights.
Regulators assess evidence. A defensible programme needs documented assessment outputs, risk rating rationale, escalation trails, and remediation tracking linked to each vendor.
Operating across multiple jurisdictions?
DORA applies to EU-regulated activities and ICT third party services supporting those activities. Map obligations to each regulated entity, branch, or subsidiary individually.
Implementing a DORA-Aligned Vendor Risk Programme: Practical Steps
Implementation does not have to take months. A structured approach with the right tooling can produce a baseline audit-ready programme in weeks.
Inventory and classify all third party relationships
Start with a complete inventory. Pull data from procurement systems, IT asset registers, payment processing records, and legal contract databases. Every third party that touches your ICT environment, data, or operational processes needs to be in scope.
Gap analysis against DORA Article 30 contractual requirements
Run every existing contract for critical and important ICT providers against the mandatory provisions of DORA Article 30. Identify contracts that are missing audit rights, sub-outsourcing notification requirements, data location provisions, or termination clauses.
Operationalise monitoring and escalation
Define what triggers a review: a vendor security incident, a credit rating downgrade, a change in sub-outsourcing arrangements, or a breach of contractual SLA. Define who receives the escalation, the expected response time, and how the outcome is documented.
Address common failures in scope, evidence, and resourcing
Most financial institutions have a vendor risk process for ICT suppliers but no coherent approach to the broader third party universe. The vendor risk management process becomes sustainable only when repetitive administrative elements are removed from human hands.
