NIS2 and DORA: From Contractual Clause to Proof of Effectiveness

Supply chain security has long been addressed through standard contractual clauses, due diligence questionnaires, and compliance statements required from suppliers. This model remains useful, but it is no longer sufficient.

The guidelines published by the National Cybersecurity Agency and the implementation of the Digital Operational Resilience Act point in the same direction: organizations must be able to explain why a supply chain is critical, which requirements have been selected, how those requirements have been made binding, and how their effective implementation is verified.

The shift is from the formal existence of a control to its demonstrability.

ACN’s New FAQs on Supply Chain Security

On July 24, 2026, ACN updated the FAQs regarding security measures for the supply chains of NIS entities.

The update covers FAQs from MSB.13 to MSB.19 and provides operational guidance on the evaluation process, selection of requirements, contractual application, verification, and proportionality.

The FAQs do not replace the NIS Decree, the Agency’s Determinations, or the basic specifications. However, they are a source that should be closely monitored, as they clarify how ACN expects the measures to be implemented in organizational processes.

A four-phase process

FAQ MSB.13 outlines the supply security management process in four phases.

The first is the assessment of the risk associated with the specific supply. The unit of analysis should therefore not be limited to the supplier as a legal entity, but should also include the specific product or service being purchased, the manner in which it is provided, and the dependencies it creates.

The second phase consists of identifying security requirements consistent with the measures implemented by the NIS entity for its information and network systems.

The third point concerns enforcement. The requirements must be incorporated into requests for proposals, solicitations, contracts, agreements, and conventions related to procurements that may have an impact on security.

The fourth phase is periodic verification. The process does not end with the signing of the contract. The party must be able to verify over time that the agreed-upon requirements are actually being met.

This sequence is important because it links activities that, in many organizations, are still managed separately. The assessment may be conducted by Information Security, the contract by Procurement and Legal, the monitoring by Vendor Management, and incident management by yet another function.

Overall responsibility thus risks becoming fragmented.

Minimum Evaluation Criteria

FAQ MSB.14 lists the minimum factors to consider when evaluating a supply:

• the supplier’s level of access to information and network systems;
• access to data and intellectual property, taking into account their critical nature;
• the potential impact of a major supply disruption;
• the time and costs required for restoration;
• The supplier’s roles and responsibilities in the governance of information and network systems.

These criteria show that criticality does not necessarily correspond to the economic value of the contract.

A supply contract of limited value can be very significant if it involves privileged access, supports an essential process, handles critical data, or requires replacement lead times that are incompatible with the organization’s operational needs.

Proportionality does not mean uniformity

One of the most helpful clarifications concerns the scope of the requirements.

FAQ MSB.15 specifies that it is not necessary to establish security requirements for all supplies. The requirement applies only to those that may have an impact on the security of the NIS entity’s information and network systems.

FAQ MSB.16 also clarifies that it is not necessary to include all the requirements contained in the basic security measures in contractual documents, nor to reproduce their text verbatim. It is necessary to incorporate their substantive content, adapting it to the supply and the risk.

This recommendation reduces the risk of two opposing errors.

The first approach involves applying the same questionnaire and the same clauses to all suppliers. This generates a large amount of information, but does not necessarily lead to a better understanding of the risk.

The second involves relying on general statements, such as the obligation to comply with applicable regulations or to implement appropriate security measures. Such wording is difficult to verify and leaves it unclear what the supplier is actually required to do.

An effective requirement should be relevant, understandable, and verifiable.

Joint Ventures, Mixed Contracts, and Different Contexts

FAQs MSB.17, MSB.18, and MSB.19 apply the principle of proportionality to more complex situations.

MSB.17 clarifies that the categories of measures must be tailored to the operational context, the level of risk, and the criticality of the NIS entity’s services. Where justified, this tailoring may even extend to the exclusion of certain categories.

MSB.18 applies to temporary consortia of companies. When the successful bidder is organized as a temporary consortium, the requirements must be met by the members that provide—even partially—the services that impact cybersecurity.

MSB.19 addresses mixed contracts. In this case as well, the requirements must be applied in a manner that is proportionate, relevant, and appropriate to the specific services awarded.

The principle is simple, but applying it requires a good understanding of the contract.

It is not enough to simply classify the entire agreement as critical or non-critical. It is necessary to understand which services involve access to systems, data processing, operational responsibilities, or significant dependencies. Only then is it possible to determine to which entities and which components of the service the requirements should apply.

What’s Changing for Third-Party Risk Management Programs

ACN’s FAQs are driving TPRM programs toward a more selective model.

Classification should be based on the supply and its potential impact. Once the criticality has been identified, the organization can define a modular set of requirements, avoiding both indiscriminate application and unwarranted exceptions.

This requires at least four skills.

The first step is to maintain a reliable inventory of relevant supplies, linked to the systems, data, and processes they support.

The second is to have consistent and documented evaluation criteria. The classification cannot depend solely on the contract owner’s perception or on annual spending.

The third step is to translate the assessment results into specific contractual obligations. These may relate, for example, to access management, incident reporting, business continuity, the use of subcontractors, the availability of records, and audit rights.

The fourth step is to determine how to monitor these obligations. Monitoring can take various forms: certifications, documentation, audits, tests, technical monitoring, or periodic meetings. The level of detail in the monitoring should be commensurate with the risk.

DORA and Cyber Risks Posed by Third Parties

For the financial sector, the main European regulation is the DORA Regulation, which takes effect on January 17, 2025.

Chapter V, comprising Articles 28 through 44, governs the management of cybersecurity risks arising from third-party suppliers and the European monitoring system for providers deemed critical.

The basic principle is clear: the use of external ICT services does not reduce the financial institution’s liability. The organization remains fully responsible for complying with regulatory obligations and managing the risks associated with the services it purchases.

This principle has practical implications.

The entity must assess the risk before entering into an agreement, evaluate the criticality of the function being supported, assess the potential risk of concentration, conduct due diligence, and set forth in the contract the elements required by the Regulation.

Supplier management is therefore an integral part of the ICT Risk Management framework; it is not an activity that can be entirely delegated to the procurement department.

The Register of Information

One of the key requirements is the Register of Information provided for in Article 28.

The register must include contractual agreements relating to the use of ICT services provided by third parties and identify those that support critical or important functions. It must be maintained at the individual level and, where applicable, at the sub-consolidated and consolidated levels.

To call it a simple list of suppliers would be an understatement.

The register links entities, contracts, ICT services, business functions, suppliers, and, where applicable, subcontractors. It enables the entity to understand its dependencies and allows authorities to obtain an aggregated view of the financial system.

From Data Collection to Monitoring

The Register of Information did not remain merely a preparatory exercise.

On November 18, 2025, the European Supervisory Authorities published the first list of Critical ICT Third-Party Providers. The designation process was based on data contained in the registers submitted by financial entities through the competent authorities.

The assessment took into account, among other factors, the provider’s systemic importance, the role of the services in supporting critical or important functions, and the level of substitutability.

This step marks DORA’s entry into the operational surveillance phase.

The data generated by individual entities contribute to the representation of the concentrations and interdependencies of the entire European financial system. Errors, omissions, and inconsistent classifications therefore affect not only an individual organization’s compliance but also the quality of the analysis conducted by the authorities.

Data quality remains a real challenge

The dry run conducted by the ESA in 2024 involved nearly 1,000 financial institutions.

Only 6.5% of the records analyzed had passed all quality checks. However, this figure does not mean that nearly all participants had submitted unusable records. Half of the remaining records had failed fewer than five of the 116 checks.

The ESAs had considered the overall quality level to be consistent with the voluntary and preparatory nature of the exercise. However, the result confirmed how difficult it is to maintain consistent data across contracts, legal entities, services, critical functions, and subcontracting chains.

The problem isn’t just a technical one.

The necessary information is often scattered across procurement, IT, Legal, Finance, Business Continuity, and department heads. Without a common governance framework, the registry risks becoming the result of periodic manual data collection efforts, which are difficult to update and reconcile.

Two regulations, a common direction

NIS2 and DORA have different scopes of application.

NIS2 addresses the security of information and network systems of entities in numerous critical sectors. DORA regulates the digital operational resilience of financial entities and focuses on ICT service providers.

The level of detail also differs. DORA mandates a highly structured recording and reporting system. The ACN measures apply the NIS framework to the national context and require a process that is proportionate to the characteristics of the service and the entity.

The overall direction, however, is the same.

Supplier risk must be assessed before the contract is signed. The requirements must be derived from the assessment. The contract must ensure that these requirements are implemented. The organization must verify compliance. The most critical dependencies must be identified and managed over time.

Questions to bring to the next review

To assess the maturity of a Third-Party Risk Management program, the following questions are particularly useful:

1. Does the classification take into account the risk associated with the specific supply, or only the supplier’s general characteristics?
2. Is it possible to determine why a particular requirement was applied, excluded, or modified?
3. Do the contractual provisions define verifiable obligations, or do they merely contain general references to safety and regulations?
4. Who reviews the evidence provided by the vendor, and who decides what actions to take when it is found to be insufficient?
5. Do inventories, contracts, business impact analyses, and regulatory records describe the same dependencies, or do they provide different representations?
6. Do changes to the service, subcontractors, or technologies used trigger a new risk assessment?

These are questions of governance even before they are questions of compliance.

The quality of a third-party risk management program does not depend on the number of questionnaires sent out or the number of clauses included. It depends on the ability to demonstrate consistency between the identified risk, the decisions made, and the controls actually implemented.

This is the area where NIS2 and DORA are gradually shifting their focus.