Most companies already manage suppliers in some form: a purchasing process, a contract template, perhaps a security questionnaire sent once at onboarding. Third party risk management (TPRM) is what turns that into a continuous discipline: knowing which suppliers you depend on, how much each dependency matters, what each one does with your data and systems, and what happens if one of them fails.
Two EU texts now make that discipline a legal obligation for a large part of the market. DORA, the Digital Operational Resilience Act, applies to financial entities and is very prescriptive about how they manage ICT providers. NIS2 applies to essential and important entities across many sectors and treats supply chain security as one of the cybersecurity risk measures every covered entity must take. They ask for different things, and a company that falls under one, the other or both needs to understand where they meet.
What is third party risk management (TPRM)?
Third party risk management is the process of identifying, assessing, monitoring and reducing the risks that come from organisations outside your own: software and cloud providers, managed service providers, outsourced development, payment processors, consultants with access to your systems. The risk can be a breach at the supplier that exposes your data, an outage that stops your service, a contract that gives you no right to audit or leave, or a dependency so concentrated that no alternative exists.
A working TPRM process has a recognisable shape. There is an inventory of suppliers, each classified by how critical it is. Critical suppliers are assessed before contracting and reviewed on a schedule afterwards. Contracts carry the security, audit and exit terms the risk requires. Changes at the supplier, from a new subprocessor to a security incident, trigger a reassessment. And there is a plan for what happens if a key supplier disappears. A questionnaire filed once at onboarding covers only the first of those steps.
What does DORA require?
DORA, Regulation (EU) 2022/2554, has applied since 17 January 2025. Its fourth pillar, ICT third party risk management, sits in Articles 28 to 44, and the articles that bind every financial entity are 28, 29 and 30. Articles 31 onwards set up the EU oversight framework for critical ICT third party providers, which concerns the providers designated by the European Supervisory Authorities rather than the financial entities themselves.
Article 28: principles and the register of information
Article 28 makes ICT third party risk an integral part of the entity's ICT risk management framework. The entity must adopt a strategy on ICT third party risk, including a policy on the use of ICT services that support critical or important functions, reviewed regularly by the management body. Before entering an arrangement it must assess whether the service supports a critical or important function, carry out due diligence on the provider, identify conflicts of interest and check that the provider meets appropriate information security standards. It must also have exit strategies for ICT services that support critical or important functions, and contractual rights to terminate in defined circumstances.
The most concrete obligation is the register of information. Article 28(3) requires the entity to maintain and update a register covering all contractual arrangements for ICT services with third party providers, distinguishing those that support critical or important functions. The full register must be made available to the competent authority on request, and the entity reports on new arrangements at least yearly. The format is not left to each entity: Implementing Regulation (EU) 2024/2956 sets standard templates, with linked tables for the entity, the providers, the contractual arrangements, the functions they support and the ICT service supply chain.
Article 29: concentration risk
Article 29 asks the entity to assess ICT concentration risk before contracting for a service that supports a critical or important function. The questions are whether the provider is easily substitutable, and whether the entity would end up with several arrangements with the same provider or with closely connected providers. Where subcontracting is involved, the entity weighs the benefits and risks of the chain, including where in the world subcontractors operate and whether the law there allows effective supervision.
In practice this is where many registers fail a supervisor's first read. An entity can have dozens of separate contracts that look independent and turn out to depend on the same cloud region or the same underlying provider. Concentration only becomes visible when the inventory records not just the direct supplier but the services and the providers beneath them.
Article 30: what the contract must say
Article 30 lists the key contractual provisions. Every ICT services contract must describe the functions and services provided, the locations where services are provided and data processed, provisions on availability, authenticity, integrity and confidentiality of data, the right to access and recover data if the provider fails or the contract ends, service level descriptions, the provider's obligation to assist when an ICT incident occurs, cooperation with the competent authorities, termination rights with minimum notice periods, and the provider's participation in the entity's security awareness programmes where relevant.
Contracts for services that support critical or important functions go further: full service level descriptions with precise quantitative and qualitative performance targets, notice and reporting obligations, business contingency plans that the provider implements and tests, participation in threat led penetration testing where it applies, unrestricted rights of access, inspection and audit for the entity and its supervisor, and exit strategies with a mandatory transition period. For a SaaS vendor selling to banks or insurers, this article is usually the first place DORA appears: as a redlined contract.
What does NIS2 require?
NIS2, Directive (EU) 2022/2555, approaches suppliers through risk management rather than through a register. Article 21(2) lists the minimum cybersecurity risk measures every essential and important entity must take, and point (d) is supply chain security, including the security aspects of the relationships between the entity and its direct suppliers or service providers.
Article 21(3) adds the detail. When deciding which supply chain measures are appropriate, entities must take into account the vulnerabilities specific to each direct supplier and service provider, the overall quality of their products and cybersecurity practices, including their secure development procedures, and the results of the coordinated risk assessments of critical supply chains carried out at EU level under Article 22. Those coordinated assessments are run by the NIS Cooperation Group with the Commission and ENISA, and they mean that a risk identified for a whole category of supplier can become something each entity is expected to weigh.
For some categories of digital provider, including cloud, data centre and managed service providers, Implementing Regulation (EU) 2024/2690 turns this into more specific requirements, among them a supply chain security policy and an up to date list of direct suppliers and service providers. In Spain, the national law that transposes NIS2 had not been published in the BOE as of mid 2026, so the directive is the reference for what the obligations will contain. The scope question, which companies are covered at all, is set out in NIS2 in Spain: who is in scope.
DORA and NIS2 side by side
Read together, the two texts aim at the same outcome by different routes. DORA tells financial entities exactly what to record and what to put in contracts. NIS2 tells covered entities to manage supply chain risk proportionately and leaves more of the method to them.
- Who it binds: DORA binds financial entities, and reaches ICT providers through contracts and, for the most systemic ones, through direct EU oversight. NIS2 binds essential and important entities in the sectors of its annexes, and reaches their suppliers through contractual requirements.
- Supplier inventory: DORA requires a register of information in a fixed format covering every ICT arrangement. NIS2 sets no single register format in the directive, though an inventory is needed to apply Article 21(3), and Implementing Regulation 2024/2690 expects one from certain digital providers.
- Assessment before contracting: DORA requires due diligence and a concentration risk assessment for services that support critical or important functions. NIS2 requires supplier specific vulnerabilities and practices to be taken into account.
- Contract content: DORA lists mandatory clauses in Article 30. NIS2 expects security requirements in supplier relationships but does not list clauses.
- Exit: DORA requires exit strategies and transition periods for critical or important functions. NIS2 covers continuity under the wider risk measures of Article 21.
- Incidents at a supplier: both expect the entity to account for them; DORA through the provider's contractual duty to assist, NIS2 through incident handling and the reporting duties in Article 23. The clocks for those reports are explained in NIS2 and DORA incident reporting deadlines.
A company that is both a financial entity and an NIS2 entity, or a supplier to customers under each, ends up answering both sets of questions. Building the inventory once, with fields that satisfy the stricter of the two, avoids running two supplier programmes that describe the same contracts differently.
Where ISO 27001 already covers the ground
Companies certified to ISO 27001 are not starting from zero. Annex A of ISO 27001:2022 has five controls on suppliers: 5.19, information security in supplier relationships; 5.20, addressing information security within supplier agreements; 5.21, managing information security in the ICT supply chain; 5.22, monitoring, review and change management of supplier services; and 5.23, information security for use of cloud services. Together they cover a supplier policy, security terms in contracts, supply chain risk, ongoing review and the specific case of cloud.
What ISO 27001 does not provide is the regulatory specificity. It does not prescribe DORA's register format, its concentration risk assessment, its list of contract clauses or its exit strategy requirements, and it does not reference NIS2's coordinated supply chain assessments. The sensible approach is to treat the ISO controls as the backbone and add the DORA and NIS2 specific fields and steps on top, rather than building a separate process for each regulation.
Building one supplier inventory that serves both
The inventory is the piece everything else depends on. Due diligence, contract review, concentration analysis and periodic reassessment all start from knowing which suppliers exist, what they provide and how much each one matters.
Classifying suppliers by criticality
Not every supplier deserves the same scrutiny, and trying to apply full due diligence to the stationery provider is how TPRM programmes stall. A workable classification starts from the function the supplier supports. Under DORA, the decisive question is whether the ICT service supports a critical or important function, meaning one whose disruption would materially impair the entity's financial performance, the continuity of its services or its regulatory compliance. Under NIS2 and ISO 27001, the equivalent is a risk rating based on data access, system access and the impact of an outage.
Three tiers are usually enough: critical suppliers that support essential functions or hold sensitive data, important suppliers with meaningful access but available alternatives, and low risk suppliers with no access to systems or data. The tier then drives everything downstream: the depth of the initial assessment, the contract terms required, the review frequency and whether an exit plan is needed.
Review frequency and evidence
A supplier assessment is a snapshot. The supplier changes its subprocessors, moves data to a new region, suffers an incident or lets a certification lapse, and the original assessment no longer describes the relationship. Both regimes expect the review to continue for as long as the contract does, and DORA expects audit and inspection rights to be exercised at a frequency based on risk.
A defensible review cycle sets a frequency per tier, for example yearly for critical suppliers and every two or three years for important ones, plus event driven reviews when something changes. Each review should leave evidence: the updated assessment, the certificates or reports checked and their expiry dates, the open findings and who owns them. When a supervisor or an auditor asks about a supplier, the answer is a dated record, not a recollection.
Finding the suppliers nobody registered
The most common gap in a supplier inventory is not a badly assessed supplier. It is the supplier nobody knows about: the SaaS tool a team signed up for with a company card, the AI assistant connected to a shared drive, the analytics service a developer added to a product. None of them went through purchasing, so none of them are in the register, and some of them hold company data.
Discovery has to come from the systems people actually log into. Single sign on logs and identity provider integrations show which applications employees authenticate to, and expense and card data show which ones are being paid for. Comparing those sources against the register regularly is the only reliable way to keep the inventory complete, and an incomplete register is a finding under DORA in its own right.
TPRM checklist
For a company that has to meet DORA, NIS2 or both, the core of a supplier programme can be checked against this list:
- A written ICT third party risk strategy and supplier policy, approved by management and reviewed on a schedule.
- A complete inventory of suppliers, including those discovered through sign on and expense data, with an owner for each relationship.
- A criticality classification for every supplier, and for financial entities an explicit flag for services that support critical or important functions.
- Due diligence before contracting, scaled to the tier, and a concentration risk check for critical services.
- Contract terms reviewed against DORA Article 30 where it applies, and against ISO 27001 control 5.20 in every case.
- A review cycle per tier, plus reassessment when a supplier changes or reports an incident.
- Exit strategies and tested alternatives for the suppliers you could not operate without.
- For financial entities, a register of information maintained in the format of Implementing Regulation 2024/2956 and ready to submit.
Most companies find that they can tick the first and fifth items and very few of the others. The gap is rarely a missing policy; it is the operating work of keeping an inventory and a review cycle alive month after month. This sits squarely within the wider DORA programme, and the third party pillar is described alongside the other four in the five pillars of DORA.
How the Qalea Supplier Dashboard supports it
Qalea's platform includes a Supplier Dashboard that holds the supplier inventory: each supplier with its risk level, whether it falls in a critical category, its review cycle and the evidence behind each review. Suppliers can be discovered through the company's single sign on, so SaaS tools that never went through purchasing appear in the inventory instead of staying invisible. Qalea's team provides guided support in running the reviews, and what a company already has, whether in another platform or in spreadsheets, is migrated in rather than rebuilt.
The dashboard is the inventory and review record that feeds a DORA register of information; it is not presented as the regulatory register itself. Financial entities still produce the register in the templates of Implementing Regulation 2024/2956, and the inventory is what makes that work reliable, because the register is only as complete as the list of suppliers behind it. The same inventory supports the supplier controls of ISO 27001, SOC 2, ISO 9001 and the ENS, so one supplier programme serves every framework a company runs.
