NIS2 Suppliers: Separate Legal Duties from Customer Requests

By DataTip · Published October 22, 2026

A customer’s NIS2-related security request does not, by itself, make your business legally subject to NIS2. NIS2 suppliers may face cybersecurity expectations through supply-chain reviews or agreements, but those expectations are not automatically statutory duties. Check your business’s legal scope under the applicable national law, then review the specific request and any contractual commitment with local counsel before treating either as binding or using it to make spending decisions.

Supplying an organization covered by NIS2 does not, by itself, establish that your business is directly subject to the directive. Verify your statutory scope under applicable national law separately from any customer or supplier request, and review the actual commitment with local counsel.

NIS2 is Directive (EU) 2022/2555. The Polish example in this article concerns its implementation through an amended Act on the National Cybersecurity System (KSC). The legal position described is as of 24 September 2026, and this article is not legal advice. The dates and sanctions below are specific to Poland; they are not a uniform EU timetable or penalty schedule.

The cited Polish overview is expressly framed around practical obligations, deadlines and consequences for small and medium-sized businesses in Poland from 2026 onward (cedepeconsulting.pl). Its opening also frames duties as applying to entities covered by NIS2, rather than establishing that every supplier to a covered entity is directly in scope (the same Polish overview).

NIS2 suppliers: does a customer request create a legal duty?

No. Supplying an organization covered by NIS2 does not, on its own, establish that your business is directly covered by the directive or the relevant national law. A customer may raise cybersecurity expectations through supply-chain assessments or an agreement, but whether those expectations apply to you – and on what basis – needs to be checked.

Keep two questions separate. First, does the law applicable to your business place it within the direct statutory scope? Second, what does the customer or supplier actually request, and have you agreed to it? A customer’s regulatory status does not answer the first question for you. Equally, uncertainty about your own statutory status does not resolve what a contract requires.

That distinction matters when prioritizing work. Treat a request as something to review, not as proof of a legal duty or a reason to dismiss the request without examining its terms.

How did NIS2 change the earlier directive?

Compared with the first NIS Directive, NIS2 broadens the range of entities covered, including more small and medium-sized businesses. The Polish account also emphasizes management responsibility and preventive cybersecurity measures, rather than relying only on checks after an incident.

The account groups the obligations for covered entities into risk management, operational security, incident handling and reporting, and management responsibility. Supply-chain security is part of that picture: covered entities assess the security of suppliers and partners. This can create practical questions or expectations for suppliers, but it does not mean every supplier has the same direct statutory duties.
The listed measures include:

• Risk management: analysing IT and business risks, documenting information-security policies, preparing incident-response procedures, and testing or reviewing whether controls work.
• Operational security: access controls, including multifactor authentication; backups and recovery tests; business continuity and crisis management; updates and vulnerability management; cryptography; and attention to supplier and partner security.
• Incident handling and reporting: detecting and documenting incidents, responding to them, and recording remedial actions. For serious incidents, the Polish account describes an early warning within 24 hours and an incident notification within 72 hours.
• Management responsibility: managers are expected to understand and make substantive decisions about the organization’s security. The Polish account includes documented management training. It also describes employee training and cyber-hygiene practices.
  These are obligation areas for covered entities. For a supplier, the relevant question is which measures a customer actually requests and whether they appear in an agreement – not whether the entire list automatically applies to the supplier by virtue of the business relationship.

Which NIS2 requirements are EU-level, and which are Polish?

NIS2 establishes common EU-level categories for covered entities, risk-management measures and incident-reporting timelines. National implementation supplies additional legal details. In the Polish account, those include entity-identification procedures, the register, the S46 system, transition periods, penalties and competent authorities. These national arrangements should not be assumed to apply in other member states.

When reviewing NIS2 supplier requirements, identify the relevant jurisdiction and distinguish the directive’s shared framework from national rules. Then examine the customer’s actual request or contract. A general reference to NIS2 does not establish your legal status or show that a particular requirement is contractually binding.

What implementation dates does the Polish account give?

The following dates concern the amended Polish KSC law, which took effect on 3 April 2026. They apply to the Polish legal account, not to every EU member state. For existing entities covered under the described rules, the account gives this schedule:

• 3 October 2026: deadline to self-identify and apply for entry in the register.
• 3 April 2027: deadline to implement the stated security-management obligations.
• 3 April 2028: first audit for specified key entities that were not previously operators of essential services.
  The account describes a transition period for implementing the stated obligations. It also notes that preparation – such as mapping processes, selecting suppliers, documenting controls and training – can take substantial lead time. These details reflect the legal position stated as of 24 September 2026; verify current Polish law before relying on them.

What sanctions and market consequences does the Polish account describe?

The account describes Polish administrative penalties for entities and a personal penalty for a manager. It gives revenue-linked maximums of up to 2% of annual revenue for a key entity and up to 1.4% for an important entity, alongside fixed statutory ceilings and minimums. The supplied source material omits the monetary amounts for those fixed figures, so they are not reproduced here. It also describes a possible penalty of up to 300% of a manager’s remuneration. These figures and rules are specific to the Polish account and its stated legal-status date – not a statement of uniform EU sanctions.

The account also identifies possible market consequences, including customer audits, terminated agreements, exclusion from supply chains and reputational damage in business-to-business relationships. Such consequences may arise before a regulatory decision. They do not, however, determine whether your business is legally in scope or replace the need to assess an actual contractual commitment.

What should you verify before treating a request as an obligation?

Confirm your business’s direct statutory scope under the law that applies to it. Separately, review the specific customer or supplier request and any relevant agreement. Ask local counsel to verify current national rules and distinguish legal duties from contractual expectations before treating either as binding or using it as a basis for spending decisions.

That review helps avoid two different mistakes: overlooking a genuine legal duty and assuming that a customer request makes every supplier legally covered. If the request is contractual, its significance depends on the commitment itself. If your statutory status is unclear, resolve that independently rather than relying on a customer’s classification.

Frequently asked questions

Does supplying an NIS2-covered company make a business legally subject to NIS2?

No. A supplier relationship alone does not establish direct statutory coverage. A customer may raise cybersecurity expectations through supply-chain processes or agreements, but verify your legal status separately and review the actual request with local counsel.

How can a business distinguish NIS2 duties from customer requirements?

Check which national law applies and whether your business falls within its scope. Then review the specific request and any relevant contract. A statutory duty and a customer’s contractual expectation are different questions; local counsel can help confirm how each applies.

Do the Polish dates and sanctions apply across the EU?

No. The register, S46 system, dates, authorities and sanctions described here concern the Polish implementation account, which states its legal position as of 24 September 2026. Verify the rules in the relevant jurisdiction before relying on those details.

Key takeaways

• A customer’s NIS2 status does not by itself establish that a supplier is directly within statutory scope.
• Assess applicable legal duties separately from requirements raised through a customer or supplier relationship.
• The register, S46 system, dates and sanctions described here are specific to the Polish account and its stated legal-status date of 24 September 2026.
• Verify current local law and the actual agreement with counsel before treating a request as binding or using it as a basis for spending decisions.

Practical tips

• When a customer raises a cybersecurity requirement, identify the request and any agreement it relates to; do not assume it is automatically a statutory duty.
• Check the jurisdiction and legal-status date behind any NIS2 timeline or penalty information used in planning.
• Compare existing policies, incident procedures, training and supplier assessments with the measures actually raised in the request.