What DORA and NIS2 mean for third-party cyber risk management
Discussions about DORA and NIS2 sometimes give the impression that regulators have discovered an entirely new category of risk. This is simply not true. Critical providers have always existed. Organizations have often relied on a relatively small number of vendors whose disruption would interrupt essential operations. Concentration risk has existed for decades, particularly as cloud computing and software markets consolidated around a handful of dominant providers.
Supply chain failures are equally familiar. The difference is not that these risks suddenly appeared. The difference is that regulators are no longer willing to accept that organizations understand them only in theory. DORA and NIS2 make those expectations explicit. DORA and NIS2 also come at a time when third-parties are a rapidly increasing component of breaches. Through these regulations, the EU is attempting to protect its critical infrastructure and businesses from a significant source of risk.
The emphasis shifts from demonstrating that third-party risk management exists to demonstrating that it produces meaningful understanding of operational dependency. Accountability becomes more visible because regulators increasingly expect organizations to explain not simply which vendors they use, but why those relationships matter, which business services depend upon them and how disruption would be managed if those relationships failed.
For many organizations, this represents a more significant change than any individual regulatory requirement.
Why regulators focus on resilience, not checklists
The most important shift within both DORA and NIS2 is philosophical rather than procedural. Completing an assessment is not the objective. Understanding resilience is.
Traditional vendor risk programs often revolve around activities:
- A questionnaire is completed
- Evidence is collected
- Findings are documented
- Contracts contain appropriate language
- Reviews occur on schedule
Every individual task may satisfy internal policy while revealing surprisingly little about whether the organization could continue operating during a significant third-party disruption. That is precisely the gap regulators increasingly seek to close.
Effective third-party risk management begins with identifying which vendors support critical business services rather than simply identifying which vendors process sensitive information. Those are related questions, but they are not identical.
An organization may depend upon an infrastructure provider, an identity management platform, or a telecommunications service whose failure would halt operations despite storing relatively little confidential information. Conversely, another supplier may process sensitive data without representing the same level of operational dependency.
The difference here is critical because resilience depends upon business impact rather than administrative categorization. Understanding operational dependency therefore requires organizations to answer questions that extend well beyond traditional vendor governance:
- Which suppliers support critical services?
- Which failures would interrupt customer operations?
- Which dependencies lack practical alternatives?
- Where has the organization become concentrated around a single technology provider, region, or subcontractor?
These are resilience questions before they are compliance questions.
Under DORA third-party risk requirements, financial entities are expected to establish stronger governance around ICT providers, maintain comprehensive information about third-party relationships, assess risks throughout the vendor lifecycle and strengthen oversight of providers supporting critical or important functions. The regulation reflects an understanding that operational resilience cannot be separated from the resilience of external technology providers.
NIS2 extends similar thinking across a broader range of essential and important sectors by reinforcing supply chain security expectations and increasing executive accountability for cybersecurity outcomes.
Different regulations. Similar philosophy.
DORA and NIS2 compliance does not equal resilience
One of the more dangerous assumptions organizations can make is believing that regulatory compliance and operational resilience are interchangeable. They are not. For example:
- Contracts can satisfy regulatory expectations
- Vendor files can be complete
- Due diligence documentation can be current
- Risk ratings can be updated exactly as policy requires
None of those guarantees the organization will continue delivering critical services during a significant third-party disruption. The difference is becoming important because cyber incidents rarely expose weaknesses in documentation. They expose weaknesses in operational understanding.
Organizations discover that a critical application depends upon an overlooked subcontractor. A regional outage affects multiple suppliers simultaneously because they rely upon the same cloud infrastructure. Recovery plans assume alternative providers exist when no realistic alternatives can be implemented quickly enough. Those are not documentation failures but dependency failures.
The purpose of third-party cyber risk management therefore changes. Rather than asking only whether a vendor meets minimum security expectations, organizations increasingly need to understand how technology dependencies interact across the enterprise and where seemingly independent suppliers create common points of failure.
That perspective is more valuable during disruption than another completed assessment questionnaire.
