Sixty-two per cent of security incidents reported to ANSSI in 2025 involved third-party access or a compromised supplier component. Yet when organisations review their contract portfolios through the NIS2 lens, the same finding comes up: the security clauses exist, but they do not cover what the directive now requires.
NIS2 is not only an internal obligation. Article 21 explicitly requires essential and important entities to manage the risks linked to their supply chains, including ensuring that their suppliers meet proportionate security requirements. In other words: your compliance depends on that of your critical subcontractors. What your contracts say today, or fail to say, partly determines your exposure.
In this article, you will see the three most frequent contractual gaps we observe during portfolio audits, how to qualify supplier risk quickly without launching a full audit, and what compliance concretely involves.
The framework: NIS2 and the supply chain obligation
Article 21 of the NIS2 Directive lists the security measures entities must implement. Among them: "supply chain security, including security-related aspects concerning the relationships between each entity and its direct suppliers or service providers". The text does not merely recommend general vigilance: it requires a structured approach.
In practice, this means you must identify your critical suppliers (those whose compromise would significantly affect your systems or services), assess their security level, and have contractual mechanisms that allow you to exercise oversight and, if necessary, to act.
The ENISA guides published in March 2026 clarify the notion of "critical supplier": any provider that processes your sensitive data, accesses your information systems, or whose failure would directly disrupt your business continuity. For a mid-sized organisation, this scope often goes beyond IT services firms and software publishers: it includes industrial maintenance providers with remote access, cloud integrators, and communication service providers.
Gap 1: no incident notification obligation
Most service contracts signed before 2025 contain a data confidentiality clause, sometimes a general security clause, but rarely an explicit obligation to notify a security incident within a defined period.
NIS2 requires essential entities to notify ANSSI within 24 hours of detecting a significant incident. If that incident originates with a supplier, which is the case in most supply chain compromises, you must be informed in time. A contract that does not set this deadline exposes the entity to a double risk: failing to notify, or notifying on the basis of incomplete information.
What the contract should provide: an incident notification clause with a 24-hour deadline, a defined communication channel, an identified contact at the supplier, and an obligation to transmit the technical information needed to qualify the incident.
Gap 2: no real audit right
Contracts often include an audit right, but drafted so restrictively that it becomes ineffective. Notice periods of 60 to 90 days, a scope limited to "general security practices", and an implicit refusal to share third-party penetration test reports: these formulations protect the supplier, not the entity.
A concrete example: a healthcare organisation that suffered a compromise at its hosting provider discovered, during the incident response phase, that its contract gave it access only to ISO 27001 certification reports, and not to access logs or the configurations of its hosted environment. The contractual audit right was, in practice, only a right to request a document.
What the contract should provide: a real audit right covering access logs for your environment, the security configurations that concern you, and the results of recent security tests. Certifications (ISO 27001, SOC 2) can complement this right, but they cannot replace it.
Gap 3: no cascading subcontracting clauses
A supplier that meets your security requirements may itself rely on subcontractors that do not. NIS2 requires cascading thinking: you are responsible for your entire chain, including the levels you do not contract with directly.
In practice, the great majority of contracts signed with IT services firms or SaaS publishers contain no clause requiring their own suppliers to meet standards equivalent to those you impose on them. This asymmetry is a frequent blind spot, and one of the most exploited attack vectors in 2025 (attacks such as Kaseya and SolarWinds: in both cases, the initial vector was a level 2 or level 3 provider).
What the contract should provide: a downstream flow-down clause requiring your security obligations to be passed on to the provider's subcontractors who access your data or systems, with an obligation to notify you if that scope changes.
How to quickly qualify your supplier risk
A full contractual audit of a portfolio of 50 suppliers takes several weeks. A more pragmatic approach is to prioritise critical suppliers first, then analyse them against three criteria.
Criticality: does this supplier access my systems, process my sensitive data, or would its failure interrupt my activity?
Contractualisation: are the three gaps above (notification, audit, cascade) covered in the existing contract?
Effective capability: beyond the contract, does this supplier actually have the security practices it certifies? A standardised questionnaire (CAIQ, SIG) or the sharing of recent reports (penetration test, certification) allows rapid qualification without committing to a full audit.
This three-variable matrix makes it possible to sort a portfolio of 50 suppliers in a few days, and to identify the 5 to 10 contracts that require priority revision.
What compliance concretely involves
Revising a service contract with an IT services firm or a cloud host generally takes 4 to 8 weeks, depending on the supplier's responsiveness and the complexity of the clauses to negotiate. Hyperscale providers (AWS, Azure, GCP) offer standardised "NIS2-ready" addenda, but these do not always cover the specifics of your context, in particular the notification obligations towards ANSSI.
Smaller providers are often willing to revise their contracts, provided you propose a clause template rather than an open request. Having an internal template of NIS2 security clauses is a significant accelerator.
Presidio allows you to map your supplier portfolio, document the contractual status of each critical provider, and track the progress of contract revisions within the same workflow as your other NIS2 obligations. To frame your exposure and prioritise the contracts to revise first, a 30-minute conversation is enough. See also our analysis of third-party governance and TPRM under NIS2.
Conclusion
Supplier contracts are not a legal topic: they are an attack surface. Three gaps (notification outside the deadline, an ineffective audit right, no flow-down to subcontractors) account for the great majority of the contractual exposures we observe. The organisations moving fastest on this topic do not audit all their suppliers at once: they prioritise the 5 to 10 critical contracts, define an internal clause template, and proceed provider by provider.
NIS2 contract compliance is not an 18-month project. It is a 6 to 8 week project, well targeted.
Also read: Third-party governance under NIS2/DORA and SBOM and software inventory under NIS2/DORA.