Brandefense Academy Your trusted hub for learning, developing, and mastering the skills that shape tomorrow's digital defense.
Discover Now
RESOURCES TYPES
Brandefense Academy Your trusted hub for learning, developing, and mastering the skills that shape tomorrow's digital defense.
Discover NowJULY 3, 2026
Two regulatory frameworks now govern how European organizations 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 and imposes supply chain security obligations on essential and important entities across 18 sectors. DORA, the Digital Operational Resilience Act, has applied to financial entities since January 2025 and imposes a more prescriptive and detailed set of ICT third-party risk requirements, including a mandatory Register of Information that regulators are already auditing.
The compliance story in 2026 is no longer about understanding what these frameworks require. It is about demonstrating that you have implemented what they require, continuously, with evidence. The second annual DORA Register of Information submission cycle closed in March 2026. Supervisors across Germany, the Netherlands, and France have signaled that persistent register deficiencies are an enforcement priority. NIS2’s October 2026 deadline for member state compliance is approaching, with national transposition laws now in force across the majority of EU jurisdictions.
For compliance and security teams, the operational challenge is the same regardless of which framework applies: third-party risk cannot be managed with periodic questionnaires, point-in-time audits, and static contract clauses. Both NIS2 and DORA, read carefully, require continuous visibility into the security posture of vendors and the exposure they create. This blog maps the specific requirements of each framework, identifies where compliance gaps most commonly appear, and explains what a program that satisfies both looks like in practice.
| Oct 2024 NIS2 transposition deadline; requirements 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 | Oct 2026 NIS2 national enforcement deadline; active supervisory cycle now underway |
NIS2 addresses supply chain and third-party risk primarily through Article 21, which requires essential and important entities to implement appropriate and proportionate technical and organizational measures to manage cybersecurity risks. Article 21(2)(d) explicitly includes supply chain security among the mandatory measures, covering security in the relationships between the entity and its direct suppliers and service providers.
This is broader than it may initially appear. NIS2 does not limit supply chain obligations to direct technology vendors. It covers any supplier or service provider whose compromise could affect the entity’s ability to maintain the security of its network and information systems. Physical security vendors, facilities management providers, and non-technology supply chain partners are all potentially in scope if their failure would have a material cybersecurity consequence.
| Obligation | What It Requires | Compliance Evidence Expected |
| Supply chain risk assessment | Entities must assess and manage cybersecurity risks arising from their supplier and service provider relationships, including the security practices of each provider | Documented vendor risk assessments, tiering methodology, periodic review records |
| Supplier security practices evaluation | Entities must consider the overall quality of the security products and practices of their suppliers, including secure development practices | Vendor questionnaires, certification verification (ISO 27001, SOC 2), contractual security requirements |
| Shadow IT and digital asset inventory | A complete inventory of information systems including SaaS and cloud services is required; shadow IT must be detected and documented | 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 originating 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 undergo 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 addressing business continuity in the event of 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 organizations in scope may have lighter documentation requirements. However, proportionality does not exempt any in-scope entity from the substance of the supply chain security obligation. It affects how the obligation is implemented, not whether it exists. In practice, proportionality arguments that result in no formal vendor risk assessment process, no incident reporting capability for supply chain events, and no documentation of supplier security practices are unlikely to withstand supervisory scrutiny. The 38% of Irish businesses that survey data showed would not be compliant by October 2024 did not generally cite proportionality as a defense. |
DORA’s third-party risk management framework is more detailed and prescriptive than NIS2’s supply chain security provisions. It occupies Chapter V of the regulation (Articles 28 through 44) and establishes a complete governance structure for managing ICT third-party dependencies from initial due diligence through contract execution, ongoing monitoring, and exit planning.
The defining feature of DORA’s TPRM approach is the Register of Information: a mandatory, structured record of every contractual arrangement with an ICT third-party provider that must be maintained, updated, and submitted annually to national competent authorities. The register is not a document. It is a database with prescribed fields, and regulators are using it to identify concentration risk, subcontractor opacity, and missing contractual provisions at scale.
| Obligation | Article | What It Requires |
| ICT third-party risk policy | Art. 28(2) | Financial entities must adopt and maintain a formal strategy for ICT third-party risk, reviewed at least annually, covering the full lifecycle of provider relationships |
| Pre-contractual due diligence | Art. 28(4) | Before entering 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, submitted annually to national competent authorities; must include subcontractor chains supporting critical functions |
| Contractual minimum provisions | Art. 30 | Contracts with ICT providers must include audit rights, incident cooperation obligations, data location and portability rights, subcontractor disclosure requirements, and exit plan provisions |
| Critical function provider designation | Art. 28(5) | Entities must identify which ICT providers support critical or important functions and apply enhanced oversight to those relationships |
| Concentration risk management | Art. 29 | Entities must assess and manage concentration risk arising from dependence on a single provider or a small number of providers for critical functions; multi-vendor strategies must be documented |
| Exit planning | Art. 28(8) | Entities must document exit strategies for ICT providers supporting critical functions, including transition timelines, alternative provider identification, and data portability procedures |
| Ongoing monitoring | Art. 28(6) | Entities must continuously monitor the performance and security posture of ICT providers supporting critical functions; periodic reviews are required at minimum annually |
| Incident reporting from providers | Art. 30(2)(j) | Contracts must require ICT providers to report incidents to the financial entity promptly, with defined timelines for notification of major incidents affecting the financial entity |
The DORA Register of Information has been the single most operationally challenging compliance requirement for in-scope financial entities. The 2025 pilot submission round exposed a consistent pattern: organizations that believed they had comprehensive vendor relationships documented discovered they lacked a centralized view of ICT contracts, with arrangements scattered across procurement teams, business units, and subsidiary operations.
The 2026 enforcement shift has made the register a priority audit target. Supervisors are looking for completeness (all ICT arrangements documented, not just the major ones), accuracy (subcontractor chains traceable for critical functions), and currency (updated to reflect contract changes within defined timeframes). A register that cannot answer the question ‘which of our ICT providers support critical functions, and who are their subcontractors’ is, as regulators have stated explicitly, a documented compliance failure.
| 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 demonstrate in their Register of Information that they have assessed and mitigated the concentration risk arising from those dependencies. This is not a one-time assessment. It is an ongoing obligation that must be reflected in both the register and in the entity’s concentration risk management documentation. For organizations using multiple cloud providers from the CTPP list, the concentration risk assessment must address the scenario in which two or more designated CTPPs experience simultaneous incidents, and the entity’s ability to maintain critical functions in that scenario. |
For organizations subject to both frameworks, the practical compliance question is which requirement controls where they overlap and what additional obligations each framework adds independently. The general rule is that DORA functions as lex specialis for the financial sector: where DORA and NIS2 address the same topic, DORA’s requirement is the binding one for in-scope financial entities.
| TPRM Area | NIS2 Requirement | DORA Requirement | Which Controls for Financial Entities |
| Vendor inventory | Digital asset and supplier inventory required; shadow IT must be documented | Register of Information: structured database with prescribed fields, annual submission to regulators | DORA: more prescriptive, annual submission obligation |
| Due diligence | Assess supplier security practices; consider quality of security products and development practices | Formal pre-contractual due diligence covering security, financial stability, continuity, and subcontractor chains | DORA: more detailed scope and documentation standard |
| Contractual requirements | Appropriate security clauses in supplier contracts implied by risk management obligations | 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 continuous risk management obligation | Explicit ongoing monitoring requirement under Article 28(6); at minimum annual formal review | DORA: explicit obligation with minimum frequency |
| Incident reporting from vendors | Vendors should cooperate with incident response implied by supply chain security obligations | Contracts must require prompt vendor notification of incidents affecting the financial entity, with defined timelines | DORA: explicit contractual obligation |
| Concentration risk | Not explicitly addressed; implied by supply chain resilience requirement | Explicit concentration risk assessment and management requirement under Article 29 | DORA: unique obligation with no NIS2 equivalent |
| Exit planning | Business continuity measures must address supply chain disruption | Documented exit strategies 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 within 4h initial notification, 24h intermediate, 72h final, 1 month follow-up | 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 requirements and a red bar for DORA requirements. 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 obligation. Concentration risk and the Register of Information are DORA-only.’ Brand navy background. |
A compliance gap analysis for NIS2 and DORA TPRM obligations begins with determining which framework applies to which parts of the organization, then mapping current program capabilities against each specific requirement. The output is a prioritized list of gaps, organized by the severity of the supervisory risk they create.
| Requirement | Gap Indicator | Typical Finding |
| Vendor risk assessment process | No documented methodology for classifying vendors by risk; assessments exist but are not linked to criticality tiers | Ad hoc assessments for major vendors; no process for newly onboarded or lower-tier vendors |
| Register of Information completeness | 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 frequently absent |
| Contractual minimum provisions | Existing contracts lack audit rights, incident notification timelines, or subcontractor disclosure clauses | Legacy contracts signed before DORA are the most common gap; renegotiation timelines can exceed 12 months |
| Ongoing monitoring cadence | Vendor reviews happen at contract renewal only; no between-cycle monitoring for security posture changes | Most organizations monitor financial stability and SLA performance but not cybersecurity exposure continuously |
| Concentration risk documentation | No formal analysis of dependence on individual providers for critical functions; CTPP list not mapped to internal vendor records | Common in organizations with cloud-heavy infrastructure; three CTPPs often support 80% of critical functions |
| Exit planning | Exit clauses exist in contracts but no tested exit procedures or alternative provider identification | Plans exist on paper but have not been rehearsed; data portability provisions untested |
| Incident reporting capability | Incident classification process does not distinguish supply chain origin; 4-hour DORA timeline not built into response procedures | Most incident response plans are designed for internally originated incidents; 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 |
The most operationally efficient approach to NIS2 and DORA TPRM compliance is to build a continuous monitoring program that generates the evidence both frameworks require, rather than running separate compliance initiatives for each regulation.
The core insight is this: DORA’s Article 28(6) ongoing monitoring requirement and NIS2’s implied continuous risk management obligation both point to the same operational capability. An organization that continuously monitors the security posture of its ICT vendors, detects changes in their exposure, and documents that monitoring produces compliance evidence for both frameworks at once. An organization that relies on annual questionnaires satisfies neither.
| Monitoring Capability | NIS2 Obligation It Satisfies | DORA Obligation It Satisfies |
| External attack surface monitoring of vendor infrastructure | Supply chain security assessment; 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 | Pre-contractual and ongoing due diligence; incident detection capability 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; critical function provider oversight |
| Incident notification from vendor monitoring | Significant incident reporting within 24h/72h; supply chain incident detection | Major ICT incident reporting within 4h initial notification; vendor incident cooperation (Art. 30) |
| Concentration risk visibility | Business continuity measures; supply chain resilience | Concentration risk assessment and management (Art. 29); CTPP dependency documentation |
| Continuous asset discovery including shadow IT | Digital asset inventory requirement; shadow IT detection under NIS2 SaaS governance obligations | Register of Information completeness; ICT arrangement inventory (Art. 28(3)) |
| Brandefense Capability | Compliance Function |
| External Attack Surface Management (EASM) for vendor domains | Continuously discovers and monitors the external security posture of your ICT vendors, providing the ongoing monitoring evidence required under DORA Art. 28(6) and NIS2 Art. 21 |
| Dark web vendor credential monitoring | Detects exposed credentials and data belonging to your ICT vendors on dark web markets and forums, surfacing supply chain compromise indicators before they become incidents |
| Vendor vulnerability and exploit intelligence | Tracks CVEs and active exploitation affecting your vendors’ technology stacks, providing the security posture assessment evidence required for both pre-contractual due diligence and ongoing monitoring |
| Ransomware group targeting intelligence | Monitors threat actor activity targeting your vendors’ sectors and specific organizations, providing early warning of supply chain attack campaigns |
| Shadow IT and asset discovery | Identifies ICT services in use by your organization that may not be captured in your Register of Information, reducing completeness gaps before supervisory review |
| Continuous 24/7 monitoring with real-time alerting | Provides the monitoring cadence required by both frameworks 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: https://brandefense.io/blog/third-party-risk-management-vendor-breach-cascade/ : The operational risk dimension that underpins NIS2 and DORA’s TPRM requirements Why Vendor Security Questionnaires Do Not Work: https://brandefense.io/blog/why-vendor-security-questionnaires-dont-work/ Why periodic assessments fail to satisfy continuous monitoring obligations under both frameworks The 5-Day Breakout: https://brandefense.io/blog/breakout-time-vs-dwell-time/ : The threat timeline that gives context to incident reporting deadlines under NIS2 and DORA |
Take control of your digital security with an exclusive demo of our powerful threat management platform.
