NIS2 and DORA are two EU rules that make companies manage the cyber risk of their suppliers. NIS2 applies to essential and important entities across 18 sectors. DORA covers financial entities and has applied since 17 January 2025. Both expect ongoing visibility into vendors, but DORA is more detailed, with a mandatory Register of Information for every ICT third-party contract.
Two legal frameworks now govern how European companies manage third-party ICT risk, and both are actively enforced. NIS2, the Network and Information Security Directive 2, became applicable across EU member states in October 2024. It sets supply chain security duties for essential and important entities across 18 sectors. DORA, the Digital Operational Resilience Act, has applied to financial entities since January 2025. Its rules on ICT third-party risk are more detailed and more prescriptive. They include a mandatory Register of Information that regulators are already auditing.
In 2026 the question is no longer what these frameworks require. The question is whether you can prove, with evidence, that you do it all the time. The second annual DORA Register of Information submission cycle closed in March 2026. Supervisors in Germany, the Netherlands and France have signaled that lasting register gaps are an enforcement priority. NIS2’s transposition deadline for member states was 17 October 2024. Most EU countries now have national transposition laws in force.
Compliance and security teams face the same daily problem, whichever framework applies. Periodic questionnaires, point-in-time audits and fixed contract clauses cannot manage third-party risk. Read closely, both NIS2 and DORA ask for ongoing visibility into how secure your vendors are and what exposure they create. This blog maps what each framework asks for. It shows where compliance gaps most often appear. It also explains what a program that satisfies both looks like in practice.
| Oct 2024 NIS2 transposition deadline; needs now applicable across EU member states | Jan 2025 DORA application date for all in-scope financial entities | 19 Critical ICT Third-Party Providers (CTPPs) designated by ESAs in November 2025 |
What Does NIS2 Require for Third-Party Risk Management?
NIS2 deals with supply chain and third-party risk mostly through Article 21. It requires essential and important entities to take appropriate and proportionate technical and organizational measures to manage cybersecurity risks. Article 21(2)(d) names supply chain security among the mandatory measures. It covers security in the relationships between the entity and its direct suppliers and service providers.
This is broader than it may seem at first. NIS2 does not limit supply chain duties to direct technology vendors. It covers any supplier or service provider whose compromise could affect how well the entity keeps its network and information systems secure. Physical security vendors, facilities management providers and other non-technology partners may all be in scope. That applies if their failure would have a material cybersecurity effect.
NIS2 Article 21 TPRM Duties: Specific Needs
| Duty | What It Requires | Compliance Evidence Expected |
| Supply chain risk assessment | Entities must assess and manage the cybersecurity risks that come from their supplier and service provider relationships, including each provider’s security practices | Recorded vendor risk assessments, tiering method, periodic review records |
| Supplier security practices evaluation | Entities must weigh the overall quality of their suppliers’ security products and practices, including secure development practices | Vendor questionnaires, certification checks (ISO 27001, SOC 2), security terms in contracts |
| Shadow IT and digital asset inventory | A complete inventory of information systems, including SaaS and cloud services, is required. Shadow IT must be found and recorded | Asset inventory records, discovery tool outputs, shadow IT identification process |
| Incident reporting to authorities | Significant incidents must be reported within 24 hours (early warning) and 72 hours (full notification). Incidents that start in the supply chain are covered | Incident classification process, reporting templates, authority notification records |
| Management body accountability | Management bodies are personally responsible for approving and overseeing cybersecurity measures and must take training. Liability for non-compliance is personal | Board approval records, cybersecurity training documentation, governance meeting minutes |
| Business continuity and crisis management | Entities must have measures for business continuity after a significant cybersecurity incident, including supply chain disruption | Business continuity plans, vendor substitution procedures, critical supplier dependency maps |
| NIS2 Proportionality: What It Does and Does Not Mean NIS2 requires measures that are ‘appropriate and proportionate’ to the risk and the size of the entity. Smaller companies in scope may need lighter documentation. But proportionality does not excuse any in-scope entity from the core of the supply chain security duty. It affects how the duty is applied, not whether it exists. A proportionality argument will not hold up under supervisory review in three cases. The first is having no formal vendor risk assessment process. The second is having no incident reporting for supply chain events. The third is having no records of supplier security practices. The 38% of Irish firms that survey data showed would not be compliant by October 2024 did not generally cite proportionality as a defense. |
What DORA Requires for Third-Party Risk Management
DORA’s third-party risk management framework is more detailed and prescriptive than NIS2’s supply chain security rules. It sits in Chapter V of the regulation (Articles 28 through 44). It sets up a full governance structure for managing ICT third-party dependencies. This runs from first due diligence through contract signing, ongoing monitoring and exit planning.
The defining feature of DORA’s approach is the Register of Information. It is a mandatory, structured record of every contract with an ICT third-party provider. Companies must keep it up to date and submit it each year to national competent authorities. The register is not a document. It is a database with set fields. Regulators use it to find concentration risk, hidden subcontractors and missing contract provisions at scale.
- What it is.
- A mandatory, structured record of every contractual arrangement with an ICT third-party provider.
- Format.
- A database with prescribed fields, not a document.
- Submitted.
- Annually to national competent authorities.
- What regulators look for.
- Concentration risk, subcontractor opacity and missing contractual provisions.
DORA Chapter V TPRM Duties: Specific Needs
| Duty | Article | What It Requires |
| ICT third-party risk policy | Art. 28(2) | Financial entities must adopt and keep a formal plan for ICT third-party risk. They must review it at least once a year. It must cover the full lifecycle of provider relationships |
| Pre-contractual due diligence | Art. 28(4) | Before any ICT arrangement, entities must assess the provider’s security practices, financial stability, business continuity capability, and subcontracting arrangements |
| Register of Information (ROI) | Art. 28(3) | A complete, structured register of all ICT contractual arrangements, sent each year to national competent authorities. It must include subcontractor chains that support critical functions |
| Contractual minimum provisions | Art. 30 | Contracts with ICT providers must include audit rights, duties to cooperate on incidents, data location and portability rights, subcontractor disclosure rules, and exit plan provisions |
| Critical function provider designation | Art. 28(5) | Entities must find which ICT providers support critical or important functions and apply closer oversight to those relationships |
| Concentration risk management | Art. 29 | Entities must assess and manage concentration risk. This risk comes from relying on a single provider, or a few providers, for critical functions. Multi-vendor plans must be recorded |
| Exit planning | Art. 28(8) | Entities must document exit plans for ICT providers that support critical functions. The plans cover transition timelines, alternative providers, and data portability procedures |
| Ongoing monitoring | Art. 28(6) | Entities must always monitor the performance and security posture of ICT providers that support critical functions. Periodic reviews are required at least once a year |
| Incident reporting from providers | Art. 30(2)(j) | Contracts must require ICT providers to report incidents to the financial entity promptly. They must set clear timelines for notifying major incidents that affect the financial entity |
The Register of Information: Where Most Companies Are Failing
The DORA Register of Information has been the hardest rule to meet for in-scope financial entities. The 2025 pilot submission round showed a clear pattern. Companies that thought they had recorded all vendor relationships found they had no central view of ICT contracts. The arrangements were scattered across procurement teams, business units and subsidiaries.
In 2026, enforcement has made the register a priority audit target. Supervisors look for three things. The first is completeness: all ICT arrangements recorded, not just the major ones. The second is accuracy: subcontractor chains that can be traced for critical functions. The third is currency: updated to reflect contract changes within set timeframes. Regulators have stated that a register is a recorded compliance failure if it cannot answer one question. The question is ‘which of our ICT providers support critical functions, and who are their subcontractors’.
| The CTPP List: What It Means for Your Vendor Program In November 2025, the European Supervisory Authorities designated 19 Critical ICT Third-Party Providers (CTPPs) subject to direct ESA oversight. The list includes Amazon Web Services, Google Cloud, Microsoft, Oracle, SAP, and Deutsche Telekom among others. Financial entities that depend on any designated CTPP must show in their Register of Information that they have assessed and reduced the concentration risk from those dependencies. This is not a one-time check. It is an ongoing duty. It must show in both the register and the entity’s concentration risk records. Some companies use many cloud providers from the CTPP list. Their concentration risk assessment must cover two or more designated CTPPs having incidents at the same time. It must also cover whether the entity can keep critical functions running in that case. |
Where Do NIS2 and DORA Overlap and Where Do They Diverge?
Companies subject to both frameworks face a practical question. Which rules win where they overlap, and what extra duties does each framework add on its own? As a general rule, DORA is lex specialis for the financial sector. Where DORA and NIS2 cover the same topic, DORA’s rule is the binding one for in-scope financial entities.
| TPRM Area | NIS2 Need | DORA Need | Which Controls for Financial Entities |
| Vendor inventory | Digital asset and supplier inventory required. Shadow IT must be recorded | Register of Information: structured database with prescribed fields, sent to regulators each year | DORA: more prescriptive, annual submission duty |
| Due diligence | Assess supplier security practices. Consider the quality of security products and development practices | Formal due diligence before the contract, covering security, financial stability, continuity, and subcontractor chains | DORA: more detailed scope and a higher documentation standard |
| Contractual needs | Suitable security clauses in supplier contracts, implied by risk management duties | Explicit minimum provisions required under Article 30: audit rights, incident cooperation, subcontractor disclosure, exit planning | DORA: explicit mandatory contract clauses |
| Ongoing monitoring | Periodic review of supplier security measures, implied by the ongoing risk management duty | Explicit ongoing monitoring need under Article 28(6). A formal review at least once a year | DORA: explicit duty with minimum frequency |
| Incident reporting from vendors | Vendors should cooperate with incident response, implied by supply chain security duties | Contracts must require vendors to give prompt notice of incidents that affect the financial entity, with defined timelines | DORA: explicit contractual duty |
| Concentration risk | Not explicitly addressed. Implied by the supply chain resilience need | Explicit concentration risk assessment and management need under Article 29 | DORA: unique duty with no NIS2 equivalent |
| Exit planning | Business continuity measures must address supply chain disruption | Recorded exit plans for critical function providers required under Article 28(8) | DORA: more specific. Written exit plans required |
| Reporting to authorities | Significant incidents within 24h early warning, 72h notification | Major ICT incidents: first notification within 4h of classification (and no later than 24h after becoming aware). Intermediate report within 72h of the first notification. Final report within 1 month | DORA: stricter timeline. Satisfying DORA automatically satisfies NIS2 |
| DESIGNER NOTE: Compliance Overlap Diagram A horizontal table-style graphic showing the eight TPRM areas from the comparison table above as rows. For each row, two colored bars side by side: a blue bar for NIS2 needs and a red bar for DORA needs. Where DORA is more prescriptive, the red bar extends further right. The ‘Concentration Risk’ row has only a red DORA bar, no blue NIS2 bar, to show it has no NIS2 equivalent. Caption: ‘For financial entities, meeting DORA satisfies NIS2 on every shared duty. Concentration risk and the Register of Information are DORA-only.’ Brand navy background. |
How to Conduct a Compliance Gap Analysis: A Practical Framework
A compliance gap analysis for NIS2 and DORA TPRM duties starts by finding which framework applies to which parts of the company. Then you map your current program against each specific rule. The result is a ranked list of gaps, ordered by how much supervisory risk each one creates.
Step 1: Determine Your Regulatory Scope
- Check whether your company is subject to NIS2 only, DORA only, or both. This depends on sector, entity size and national transposition status
- If you run entities across many sectors, map each legal entity to its framework on its own. A non-financial subsidiary in the energy sector faces NIS2, not DORA
- Find out whether you are an essential entity or an important entity under NIS2. This sets your penalty exposure and how closely supervisors watch you
- Find out whether any of your ICT providers is a designated CTPP under DORA. If so, you have extra concentration risk documentation duties
Step 2: Inventory Your Third-Party ICT Relationships
- Collect all existing ICT contracts from procurement, legal, IT and business unit owners. Do not assume the central IT register is complete
- Map each contract to the functions it supports. Then sort those functions into critical, important or non-critical, using recorded criteria
- For contracts that support critical functions, trace subcontractor chains to at least the second tier. DORA’s Register of Information requires this for critical function providers
- Find gaps. Any ICT service in use without a formal contract is a shadow IT or procurement gap. It creates both a compliance risk and a security risk
Step 3: Assess Each Need Against Current Capability
| Need | Gap Indicator | Typical Finding |
| Vendor risk assessment process | No recorded method for sorting vendors by risk. Checks exist but are not linked to criticality tiers | Ad hoc checks for major vendors. No process for newly onboarded or lower-tier vendors |
| Register of Information completeness | The register covers main IT contracts but misses SaaS subscriptions, cloud services, and contracts held by subsidiaries | 60-80% completeness is common in first-year submissions. Subcontractor data is often absent |
| Contractual minimum provisions | Existing contracts lack audit rights, incident notification timelines, or subcontractor disclosure clauses | Old contracts signed before DORA are the most common gap. Renegotiation can take more than 12 months |
| Ongoing monitoring cadence | Vendor reviews happen only at contract renewal. No monitoring in between for changes in security posture | Most companies monitor financial stability and SLA performance but do not track cybersecurity exposure on an ongoing basis |
| Concentration risk documentation | No formal analysis of reliance on single providers for critical functions. The CTPP list is not mapped to internal vendor records | Common in companies with cloud-heavy infrastructure. Three CTPPs often support 80% of critical functions |
| Exit planning | Exit clauses exist in contracts but there are no tested exit procedures or named alternative providers | Plans exist on paper but have not been rehearsed. Data portability provisions are untested |
| Incident reporting capability | The incident classification process does not tell supply chain origin apart. The 4-hour DORA timeline is not built into response procedures | Most incident response plans are made for incidents that start inside the company. Vendor-initiated incidents follow a different and slower path |
| Where Are Your Largest NIS2 and DORA TPRM Compliance Gaps? Brandefense maps your vendor exposure against both frameworks and surfaces the gaps most likely to attract supervisory attention. Book a Demo |
Step 4: Rank by Supervisory Risk
- Register of Information gaps come first for DORA-covered entities. Regulators are actively auditing these and have named deficiencies as enforcement priorities in 2026
- Incident reporting gaps come second. A 4-hour DORA notification timeline needs processes and templates built ahead of time. You cannot make them up on the spot
- Fix contract gaps in legacy agreements through a structured renegotiation program. Start with contracts that cover critical functions
- Ongoing monitoring gaps are harder to close with paperwork alone. They need either a tool or a manual program that takes a lot of effort
- Concentration risk documentation can often be handled inside a compliance program. The analysis has clear limits and the output can be recorded
How Ongoing Vendor Monitoring Satisfies Both Frameworks Simultaneously
The most efficient way to meet NIS2 and DORA TPRM needs is an ongoing monitoring program that produces the evidence both frameworks ask for. This replaces a separate compliance project for each regulation.
The core insight is this. DORA’s Article 28(6) ongoing monitoring rule and NIS2’s implied ongoing risk management duty both point to the same capability. A company that monitors the security posture of its ICT vendors all the time produces compliance evidence for both frameworks at once. It also spots changes in vendor exposure and records that monitoring. A company that relies on annual questionnaires satisfies neither.
| Monitoring Capability | NIS2 Duty It Satisfies | DORA Obligation It Satisfies |
| External attack surface monitoring of vendor infrastructure | Supply chain security check. Ongoing risk management measures (Art. 21) | Ongoing monitoring of ICT third-party performance and security (Art. 28(6)) |
| Dark web monitoring for vendor credential exposure | Supplier security practices evaluation. Incident detection for supply chain events | Due diligence before the contract and throughout it. Incident detection for vendor-originated events |
| Vendor vulnerability and CVE tracking | Supply chain risk assessment. Security in supplier relationships (Art. 21(2)(d)) | ICT risk management for third-party dependencies. Oversight of critical function providers |
| Incident notification from vendor monitoring | Significant incident reporting within 24h/72h. Supply chain incident detection | Major ICT incident reporting with first notification within 4h. Vendor incident cooperation (Art. 30) |
| Concentration risk visibility | Business continuity measures. Supply chain resilience | Concentration risk assessment and management (Art. 29). CTPP dependency documentation |
| Ongoing asset discovery including shadow IT | Digital asset inventory need. Shadow IT detection under NIS2 SaaS governance duties | Register of Information completeness. ICT arrangement inventory (Art. 28(3)) |
How Brandefense Supports NIS2 and DORA TPRM Compliance
| Brandefense Feature | Compliance Function |
| External Attack Surface Management (EASM) for vendor domains | Always finds and watches the external security posture of your ICT vendors. This gives the ongoing monitoring evidence required under DORA Art. 28(6) and NIS2 Art. 21 |
| Dark web vendor credential monitoring | Detects exposed credentials and data of your ICT vendors on dark web markets and forums. It shows signs of supply chain compromise before they become incidents |
| Vendor vulnerability and exploit intelligence | Tracks CVEs and active exploitation that affect your vendors’ technology stacks. This gives the security posture evidence needed for due diligence before the contract and for ongoing monitoring |
| Ransomware group targeting intelligence | Watches threat actor activity aimed at your vendors’ sectors and at specific companies. It gives early warning of supply chain attack campaigns |
| Shadow IT and asset discovery | Finds ICT services your company uses that may be missing from your Register of Information. This closes completeness gaps before supervisory review |
| Ongoing 24/7 monitoring with real-time alerting | Gives the monitoring cadence both frameworks ask for, and the detection speed needed to meet DORA’s 4-hour incident notification timeline for supply chain events |
| RELATED READING Third-Party Risk: How Your Supplier’s Vulnerability Becomes Your Breach: Third-Party Risk: How Your Supplier’s Vulnerability Becomes Your Breach : The operational risk dimension that underpins NIS2 and DORA’s TPRM needs Why Vendor Security Questionnaires Do Not Work: Why Vendor Security Questionnaires Do Not Work Why periodic checks fail the ongoing monitoring duties under both frameworks The 5-Day Breakout: The 5-Day Breakout : The threat timeline that gives context to incident reporting deadlines under NIS2 and DORA |
For newer 2026 detail, see these pages. They cover NIS2 transposition status in 2026, what the European supervisory pages say about DORA in 2026 and the UK Cyber Security and Resilience Bill.
To put the questions into practice, use the free third-party risk questionnaire template, which includes vendor tiering, scoring and external signals to check.
For the assessment method itself, see vendor risk assessment from the outside in.