NIS2 supplier contract clauses

NIS2 customers write security clauses into supplier contracts because Article 21 reaches suppliers through agreements. This guide sets out the clauses, who drafts and owns them, and what to confirm before signing.

On this page

Which NIS2 supplier contract clauses are required and how far they reach

If your organization is an essential or important entity under NIS2, you must be able to show that supplier security is in place, and the contract is where most of that proof starts. Point 5.1.4 of the Annex to Implementing Regulation (EU) 2024/2690 says contracts must, where appropriate, set cybersecurity requirements, staff training and background checks, incident notification without undue delay, a right to audit or receive audit reports, vulnerability handling, subcontracting rules and exit obligations. Article 21(2)(d) of NIS2 carries the same duty to direct suppliers and service providers, so the requirements reach them through your contract even when the supplier is not itself in scope.

The right clause set is not the same for every supplier. It depends on the service, on whether the supplier can reach your systems, data or networks, and on the sector your entity operates in. A software licence with no remote access needs far less than a managed service that administers your firewalls. The point 5.1.4 wording is qualified by "where appropriate", which means you decide, document and justify the scope for each supplier. Your management body owns that decision, the contract and the risk you accept when a clause is missing or weakened. Ask counsel and your security lead to review the reasoning, and confirm with your competent authority if your sector guidance says more.

Start with a register that maps each direct supplier to its access level, data exposure and service criticality, then draft the clause set for each tier. Confirm with each supplier which of its own controls it will evidence, how often it will report, and how it will notify you of incidents. Note that the implementing regulation also expects you to monitor SLA reports and reassess suppliers after significant changes or incidents, so the contract should give you the information rights to do that. Illustrative example: a payroll processor with no network access may only need notification and audit report clauses, while a remote maintenance vendor needs time-limited access terms as well.

What each clause should ask for

What security requirements should a NIS2 supplier contract include?

The contract should state the security baseline the supplier must meet, tied to the services it provides, and say how compliance is shown. Where the supplier touches your systems, the clause should name the controls that matter for that service, such as access management, logging, encryption and patching. Implementing Regulation (EU) 2024/2690 expects cybersecurity requirements to be set where appropriate, so write them against the actual service scope rather than a generic checklist.

  • Ask for a written security schedule that maps to your Article 21 measures.
  • Ask for the supplier's own policies and how they are reviewed.
  • Ask for evidence such as recent test results, configuration baselines or an independent certificate, noting that a certificate does not prove every requirement.
What staff training and background check clauses does NIS2 supplier contracts need?

The clause should require the supplier to train its staff on security and to screen people who access your systems or data, where that is appropriate to the risk. The implementing regulation allows customers to extend their awareness programs and background checks to direct suppliers and service providers (points 8.1.2 and 10.2.1 of the Annex). Keep the clause proportionate: privileged staff and people with remote access warrant closer checks than staff on unrelated work.

  • Ask for a description of the training program, its frequency and who completes it.
  • Ask for confirmation that background checks follow local law and are repeated where the role changes.
  • Ask for records of completion, not just a policy statement.
How quickly must a supplier notify us of a security incident?

The supplier must notify you without undue delay of incidents that affect your services or data, so that you can meet your own reporting deadlines under Article 23. Article 23(1) requires entities to inform service recipients without undue delay where a significant incident is likely to adversely affect service provision. Do not rely on the phrase alone: agree a notification trigger, a contact route and a maximum window in the contract, and test that the route works.

  • Ask for a defined list of events that trigger notification.
  • Ask for the information the supplier will provide in the first notice and in updates.
  • Ask for a named contact and an out-of-hours route.
What audit rights should a NIS2 supplier contract give us?

The contract should give you a right to audit the supplier or to receive audit reports, so you can verify that the commitments are met. Many customers accept an independent audit report as a starting point, then keep the right to a targeted assessment after an incident or a significant change. Be precise about what a report covers, its period and its scope, because a report on one service does not cover another.

  • Ask for the most recent independent report and the bridge letter for any gap period.
  • Ask for notice periods and limits on how often you can audit.
  • Confirm whether subcontractors are included in the audit scope.
What vulnerability handling terms belong in a NIS2 supplier contract?

The clause should require the supplier to find, track, fix and report vulnerabilities in the products and services it delivers, within timeframes you agree. Under the acquisition requirements in point 6.1.2 of the Annex, you should also expect security updates for the product's lifetime or a replacement when support ends, plus information on the hardware and software components. Ask the supplier how it validates delivered products against your requirements before they go live.

  • Ask for the supplier's patch and disclosure process and its target timeframes by severity.
  • Ask for a component inventory, such as an SBOM, for software you receive.
  • Ask what happens when a vendor component reaches end of support.
How should subcontracting be handled in a NIS2 supplier contract?

The contract should say whether the supplier may use subcontractors, which ones, and what security duties flow down to them. Your obligations under Article 21(2)(d) reach your direct suppliers, and the supplier's own subcontractors can create the same exposure. Require prior notice of material changes and the right to object or terminate where a new subcontractor creates unacceptable risk.

  • Ask for a current list of material subcontractors and the services they perform.
  • Ask that the same security and notification terms apply to them.
  • Ask how the supplier reassesses subcontractors over time.
What exit and remote access terms should a NIS2 supplier contract include?

The exit clause should describe how you leave the relationship without losing data or continuity, and the remote access clause should limit how the supplier connects to your environment. Implementing Regulation 2024/2690 expects exit obligations in supplier contracts, and point 6.7.2(h) allows service provider connections only after an authorization request and for a set period, such as the duration of a maintenance operation. Time-limited access with logging is easier to defend than standing access.

  • Ask for data return and deletion steps, with timelines agreed in writing.
  • Ask for a documented access request for each connection, with an end date.
  • Ask that remote sessions be logged and reviewed.
How do we check that suppliers actually meet these contract clauses?

Monitor the supplier against the clauses over the life of the contract, not only at signature. The implementing regulation expects customers to review supplier SLA reports, look at supplier-related incidents and reassess suppliers at planned intervals and after significant changes or incidents (points 5.1.6 and 5.1.7). Keep a register that records each clause, the evidence received, the date and the owner, so that a supervisor can see the process working.

  • Ask for the evidence listed in each clause on a fixed schedule.
  • Record who reviews SLA reports and how exceptions are escalated.
  • Confirm which internal team owns each clause and who signs off a reassessment.

How to write and negotiate the clauses before signature

This sequence turns a supplier relationship into a set of documented, negotiated security terms that match what the supplier actually touches, so the contract can be signed with a clear record of why each clause exists. Each step produces an artifact your management body and a supervisor could review.

  1. Map the supplier's service and access

    Start by writing down what the supplier does for you, which systems, data and networks it can reach, and whether it reaches them remotely, through a connection you manage, or on site. Involve the business owner of the service, the system owners and whoever holds the network diagrams, because the supplier's access is often wider than the contract suggests. The output is a service and access map that lists each system, data class, connection path and privilege level. You know this step is done when the security team and the business owner both sign off that the map matches reality, including subcontractors the supplier relies on.

  2. Classify the supplier's risk

    Use the service and access map to rate how much harm a compromise or failure of this supplier could cause to your services, your data and your ability to report incidents. Weigh criticality of the service, sensitivity of the data, degree of privileged or remote access, and how easily you could replace the supplier. Article 21(3) asks entities to take into account the overall quality of products and cybersecurity practices of suppliers, so record which supplier practices you reviewed. The output is a dated risk classification record with a rating, the reasons for it and the reviewer's name. Done means the rating is approved by the person accountable for the affected service.

  3. Choose the clause depth

    Match the depth of the contract terms to the classification. A low-risk supplier with no system access may need a short schedule covering incident notice and confidentiality, while a supplier with privileged remote access to core systems will need the full set of requirements. Check which clause areas the implementing regulation names for your sector and entity type, and confirm with your legal and security leads whether a given clause is appropriate for this supplier. The output is a clause selection matrix that lists each clause area, whether it applies, and the reason it was included or dropped. Done means every dropped clause has a written justification.

  4. Draft or mark up the security schedule

    Write a security schedule that attaches to the main agreement and holds the selected requirements in operational language: staff training and background checks where appropriate, incident notification without undue delay, audit rights or access to audit reports, vulnerability handling, subcontracting rules, time-limited remote access and exit support. Where the supplier has its own security schedule, mark up its wording rather than accepting it unread. Legal counsel should review the enforceability of each clause under the governing law. The output is a negotiated security schedule with tracked changes and an issues log that records each point of disagreement and how it was resolved.

  5. Agree SLA reporting and reassessment triggers

    Define what the supplier must report and how often, which supplier-related incidents must be shared with you, and the events that will trigger a reassessment, such as significant changes to the service, a security incident at the supplier, or a change in its subcontractors. Name the people on each side who receive and act on reports. The implementing regulation expects you to monitor supplier SLA reports, review supplier-related incidents and reassess suppliers at planned intervals and after significant changes or incidents, so the contract has to make that monitoring possible. The output is a monitoring annex with reporting cadence, contacts and trigger list. Done means the monitoring owner has accepted the annex and knows the first reporting date.

  6. Sign with a review date

    Before signature, confirm that the executed version matches the negotiated schedule and that the access map, risk record and clause matrix are filed together with the contract. Record a review date in the contract register so that the supplier is reassessed on schedule and whenever a trigger occurs. Ask the supplier to confirm its contact for incident notifications and that it can meet the notification and access terms before any system access is granted. The output is a signed contract with the security schedule attached, plus a contract file that a supervisor could inspect. Done means the review date is entered in your register with a named owner.

Time-limited remote access and service provider connections

Some suppliers, such as a managed security or infrastructure provider, need recurring access to your systems. The implementing regulation (Implementing Regulation (EU) 2024/2690, Annex, point 6.7.2(h)) allows such connections only after an authorization request and for a set period, so a standing, always-on tunnel does not meet the rule even if the provider is trusted. The contract should convert ongoing access into a series of approved, bounded sessions, each tied to a named purpose and a named individual at the provider.

  • Authorization request: The provider submits a request stating the systems, accounts, purpose and planned window, and your designated owner approves it before the session opens.
  • Defined period: Access is valid only for the approved window, with the provider's standing access to production systems set to none outside that window.
  • Named users: Each session uses individual accounts with multi-factor authentication, never shared credentials.
  • Recurring review: The contract requires periodic review of standing privileges and removal of accounts no longer needed.
  • Monitoring of supplier reports: Session records feed the SLA and incident reviews you already run on the supplier.

Before signing, confirm with the supplier which access paths it uses today and whether any of them bypass your approval workflow.

Who owns the contract, the controls and the evidence

NIS2 supplier clauses only work when each party knows what it owns. The entity owns the contract terms, the risk it accepts and the evidence it presents to its supervisor, while suppliers own the controls behind those terms. Partners and auditors support that split but cannot move accountability away from the entity or make a supplier compliant on its behalf.

Management body and legal team

The management body approves the Article 21 measures and carries responsibility for infringements, so it must decide which supplier risks it accepts. Legal drafts the clauses on security requirements, audit rights, subcontracting and exit. Before signing, check that each clause maps to a risk the board has reviewed, and that the accepted residual risk is written down.

Procurement lead

Procurement runs the sourcing process, collects supplier information and keeps contract terms consistent across vendors. It should ask for the supplier's security documentation before award, including SLA reporting commitments and how the supplier handles security updates for the product's lifetime. Procurement also owns the contract register that shows which suppliers hold which clauses.

Security or compliance lead

This role writes the technical clause content and monitors it afterward. Monitoring includes reviewing supplier SLA reports, examining supplier-related incidents and scheduling reassessments after significant changes or incidents. Confirm the lead has the access, reporting lines and time to act, because clauses that nobody reviews give the entity little evidence of control.

The supplier

The supplier owns its own controls, including its staff training, background checks, vulnerability handling and internal incident detection. It must also meet the notification and subcontracting terms it signed. Ask the supplier to name the person accountable for each clause and to confirm which controls it can evidence today, rather than which it intends to build.

Implementation partner

An implementation partner such as DeployOpen can prepare systems, documentation and evidence for the clauses that its written scope covers, for example access logs, configuration records or runbooks for self-hosted platforms. It does not sign off on supplier controls or act as the entity's accountable owner. Confirm in writing which deliverables the partner provides and which remain with the entity.

Independent auditor

An independent auditor or certification body is the only party that issues a report or certificate on a supplier's controls. NIS2 creates no certificate of compliance, so any report should be read against the scope and period it covers. Ask for the report's scope statement and exceptions before relying on it, and remember that a report on one supplier does not replace the entity's own monitoring.

Questions buyers ask about supplier contract clauses

Does NIS2 require specific wording for supplier contract clauses?

No. NIS2 and the implementing regulation set the topics a contract should address, not model text you must copy. Implementing Regulation (EU) 2024/2690 lists areas such as cybersecurity requirements, staff training and background checks, incident notification without undue delay, audit rights or audit reports, vulnerability handling, subcontracting and exit obligations. Your legal counsel decides how each topic is worded, how much weight each clause carries, and how it fits your existing terms. Your supervisor will look for evidence that each topic was considered and, where appropriate, written into the agreement. Ask counsel to map each clause back to the relevant topic so the link is visible during an inspection.

Do small suppliers have to sign NIS2 clauses too?

NIS2 does not require a particular supplier to sign anything. Article 21(2)(d) obliges your organization to address security in its relationships with direct suppliers and service providers, so the duty sits with you. Whether a small supplier needs the full set of clauses depends on what it accesses, handles or operates for you. A supplier with remote access to production systems needs stronger terms than one that supplies office equipment. Where the supplier is too small to negotiate, you can still apply proportionate measures such as security questionnaires, limits on access and documented reassessment. Confirm the approach with your counsel and your national competent authority's guidance, because enforcement practice varies by Member State.

How long does negotiating NIS2 supplier clauses take?

The time depends on the scope of the contract, the number of suppliers, how much each supplier must change, and how many rounds your legal and security teams need. No timeline figure is supplied for this topic, so treat any number you hear as a claim to verify. A short addendum for a low-risk supplier can move quickly. A managed service or cloud agreement with remote access, subcontracting and exit terms usually takes longer because each clause touches operations, liability and pricing. Ask suppliers early which clauses they already accept and which need escalation. Build the negotiation calendar around your contract renewal dates so you are not forced to accept weaker terms under deadline pressure.

Does DeployOpen draft NIS2 supplier contract clauses?

DeployOpen does not draft or negotiate contracts and does not provide legal advice. Its role is to prepare systems and evidence for compliance, such as access controls, logging, backup records, vulnerability handling procedures and documentation that supports the clauses your organization agrees. Where your contracts require a specific technical measure, such as time-limited remote access for a maintenance window or a defined incident notification path, DeployOpen can implement and document that measure in the self-hosted platforms it manages. Your legal counsel reviews and finalizes every clause. Independent auditors and certification bodies issue any reports or certificates that a supplier provides.

What must our organization do internally before sending clauses to suppliers?

Your organization owns the contract and the accountability for NIS2 compliance, so several internal steps come first. Start with an inventory of direct suppliers and service providers and the access, data and systems each one touches. Classify them by risk, then agree which clause topics apply to each class. Involve legal counsel, procurement, the security lead and the business owner of each relationship. Confirm that management has approved the approach, since Article 20 places oversight duties on the management body. Finally, set up the monitoring that the contract will rely on: SLA report reviews, supplier incident reviews and planned reassessments. Clauses without a process to enforce them will not satisfy a supervisor.

Can we rely on a supplier's certificate instead of negotiating clauses?

A certificate can support your assessment, but it does not replace contract terms. NIS2 creates no certificate of compliance, and a supplier certificate shows only what its scope covers on the audit date. The implementing regulation expects you to address incident notification, audit rights or reports, subcontracting and exit obligations in writing, where appropriate. A certificate does not give you the right to receive an incident notice, to limit a subcontractor or to exit cleanly. Use the certificate as one input to your supplier review and keep the contractual rights as a separate requirement. Ask counsel to confirm the exact rights your contract needs.

What happens if a supplier refuses the security clauses we need?

Your options are to accept a documented residual risk with management approval, limit what the supplier can access, add compensating controls on your side, or replace the supplier. Each option should be recorded in your risk assessment with the reason and the owner who accepted it. For suppliers with remote access, you can restrict connections to an authorization request for a set period, such as the duration of a maintenance operation, and log every session. Refusal is also a signal for the reassessment process, so review whether the relationship still fits your risk appetite. Keep the decision and its evidence on file, because your supervisor will ask how the gap was handled.

How should we handle subcontractors when our supplier uses its own suppliers?

Your contract should say whether the supplier may subcontract, under which conditions, and what notice you receive. Ask for a current list of material subcontractors, require that they meet equivalent security terms, and keep the right to object or terminate if a change weakens protection. Confirm that incident notification and audit rights flow down to the subcontractor or are otherwise available to you. Subcontracting questions also belong in your reassessment cycle, because a change in the supply chain is a significant change that should trigger a review. Confirm the exact flow-down wording with your counsel, since it depends on the contract and the jurisdiction.

What to check before engaging outside help on contracts

Supplier contract clauses sit where legal drafting, technical requirements and vendor commitments meet. Each card below covers one thing to settle before an outside party touches the contract, so that the clauses reflect what your management body has actually decided.

Legal counsel with EU regulatory experience

Your contracts must carry NIS2 obligations down to direct suppliers, and national transposition laws differ in how they treat those obligations. Ask counsel to show experience with NIS2 national laws in the Member States where you operate, and with the supplier terms your sector already uses. Check that they will draft clauses for incident notification, audit rights and exit, and that they will say which points need your management body's decision. Ask who holds the engagement, who advises on privilege and who is accountable if a clause proves unenforceable.

A security advisor for technical requirements

Lawyers can write a right to audit, but someone technical must define what the supplier is audited against. A security advisor turns Implementing Regulation 2024/2690 expectations into specific requirements for vulnerability handling, staff training, remote access and component information. Ask for a written list of technical requirements mapped to each clause, and confirm the advisor can explain which requirements apply to your supplier type. Make sure the advisor works for you and not for the supplier.

A defined scope and written deliverables

Before signing an engagement, check that the proposed partner has a written scope listing the suppliers, contract types, clauses and documents to be produced. Vague promises to review contracts generally are a warning sign. Ask for each deliverable to be named, with its acceptance criteria and who signs it off. Confirm what is excluded, such as negotiation with the supplier, and what happens if the scope grows during the work.

Questions to settle before signing

Ask who owns the evidence produced during the engagement, including supplier reports, audit findings and incident records, and whether you can keep copies after it ends. Ask what happens at exit: how data and configurations return to you, how access is revoked, and how long the partner keeps records. Confirm who receives notices from your suppliers and how quickly they reach your management body. Put the answers in writing before the contract is signed.

How DeployOpen supports supplier security evidence

DeployOpen works on the technical side of NIS2 supplier contract clauses: the security controls, logs, access paths and evidence that a contract clause only promises. We prepare systems and documentation so your team can show a supervisor how supplier obligations are met, while the contract itself, its negotiation and its legal wording remain with your legal and procurement teams.

How we scope

  • Written scope names the supplier-facing systems, remote access paths and evidence sources covered by the clauses
  • Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts
  • Scope lists which clause areas your counsel owns and which technical checks DeployOpen prepares for them

How we build

  • Time-limited supplier access is configured for self-hosted platforms with approval, expiry and session logging
  • Incident notification routes and log retention settings are implemented in your own infrastructure
  • Security testing of supplier-facing applications and APIs can verify that agreed controls operate as written

How we hand over

  • Documentation maps each supplier clause to the configured control, the owner and the evidence produced
  • Runbooks cover revoking supplier access, handling supplier-reported incidents and requesting audit records
  • Handover includes a checklist your team can use to confirm clause evidence at planned supplier reassessments

How we support

  • Ongoing support, upgrades and continuous testing are available as retainers after handover
  • Retainers can cover periodic review of supplier access logs and changes to clause-related configurations
  • DeployOpen prepares evidence for independent assessors, but does not issue audit reports or certifications

Sources and further reading

Talk to our team.

Tell us what you're working on, whether it's a deployment, an audit, a security test or a cyber range. You'll speak with an engineer who can help you scope it.

  • 30-minute call: free, with no obligation.
  • NDA on request: we can sign before you share details.
  • Clear next steps: a scope and plan after the call.