NIS2 and Poland's KSC Act: what belongs in a software supplier contract?

A software company maintains a customer’s ordering, healthcare, logistics or production system. It does not consider itself an essential or important entity. The customer nevertheless sends a security questionnaire and contract amendment: report every incident within two hours, pay for annual audits, obtain consent for every subcontractor and guarantee “full compliance with KSC”.

The customer’s supply-chain assessment can justify additional requirements. It does not automatically justify every clause in the proposed amendment.

Allocate tasks, response times and liability to the service the supplier actually controls. This article addresses Poland’s National Cybersecurity System Act, commonly called the KSC Act, and its implementation of the EU NIS2 Directive. The Polish amendment entered into force on 3 April 2026, with transition arrangements. Entry into force did not make every new entity subject to every operational duty immediately.

NIS2 is a directive implemented through national law. Poland’s scope, procedures and transition rules should not be presented as identical across EU Member States. A separate EU implementing regulation also applies to specified categories of digital providers.

What you will learn

In brief

• ICT supply-chain security is part of the customer’s risk-management duties.
• Writing code for a regulated customer does not by itself make the supplier an essential or important entity.
• A one-hour or two-hour supplier alert is a contractual arrangement, not a universal statutory deadline for every IT business.
• Annual supplier audits at the supplier’s expense and a guarantee of the customer’s entire compliance are not automatic KSC requirements.
• Check the entity’s status and transition rules, especially for existing operators of essential services.

Is a software development company directly covered?

Not simply because its customer is covered. Assess the supplier’s actual services, size, jurisdiction and any special statutory criteria. “Software house”, a term widely used in Poland for a software development business, is not itself a legal classification.

The KSC Act’s managed-service-provider definition concerns installation, operation or maintenance of ICT products, services, processes or information systems through assistance or active administration. Review recurring maintenance, active environment administration, access and configuration management, monitoring, managed cloud or hosting, and managed security services.

The starting point is Articles 2 and 5 and the annexes of the KSC Act. Developing an application and handing it over does not automatically establish coverage. Nor does every SaaS business fit the same provider category.

Document the outcome of your assessment and its basis. A questionnaire answer saying “not applicable” solely because the company describes itself as a developer may miss an ongoing managed service.

For providers within its scope, including specified cloud, managed-service and managed-security providers, Commission Implementing Regulation (EU) 2024/2690 further specifies risk-management requirements and significant-incident criteria. It is not a voluntary checklist or a rule to apply indiscriminately to every development company.

Why do customer requirements reach the supplier?

Article 21(2)(d) of NIS2 addresses supply-chain security, including relationships with direct suppliers and service providers. Poland’s KSC framework includes ICT supply security and continuity in the information security management system, known in Polish as SZBI.

The customer therefore needs to understand service dependencies, supplier access, important subcontractors, vulnerability handling, incident cooperation and recovery. It also needs evidence that agreed controls operate.

The requirements should match the customer’s actual classification and the importance of the system. A medical provider is not automatically in the same position as every other provider. Centrum e-Zdrowia’s guidance, in Polish, helps healthcare organisations assess coverage.

The Commission’s Toolbox to improve ICT supply chain security can support the risk discussion. It is guidance, not a law requiring an identical contract amendment for every supplier.

What should a cybersecurity schedule cover?

Tie it to the services, systems and environments in the contract. A public event website and a medical-record platform may require very different controls.

Review six areas:

• Incidents: relevant events, first alert and information updates.
• Vulnerabilities: urgency, remediation ownership and interim measures.
• Audit: evidence, inspection scope, process and costs.
• Subcontractors: important providers, change notices and objections.
• Continuity: backup, recovery targets and external dependencies.
• Liability: responsibility for specified breaches and tasks retained by the customer.

Before accepting “full KSC compliance”, identify the system, duty and process you are expected to control. Those details determine the effort, price and risk.

How quickly must incidents be reported?

A supplier’s contractual alert to the customer and a regulated entity’s statutory report to a Computer Security Incident Response Team, or CSIRT, serve different purposes.

The Article 11 KSC procedure generally requires an early warning of a serious incident without delay and no later than 24 hours after detection, a notification no later than 72 hours, and a final report within a month of that notification. Exceptions, including trust-service-provider rules, and ongoing-incident provisions need separate assessment.

Check when the particular entity must use that procedure under the transition rules. The outer time limit also does not justify waiting if a report can be made earlier.

The customer may need facts from its supplier much sooner. A one-hour or two-hour alert can be agreed, but define the relevant event or credible suspicion, when the clock starts, out-of-hours coverage, first-message content, backup channel and recipient.

The first alert should not wait for a completed root-cause analysis. Initial facts about symptoms and the affected environment can be followed by timed updates. A promise of round-the-clock alerts also needs staffing and a commercial model that support it.

Who classifies and reports the incident?

Not every technical event is a serious incident. However, an event without an attacker can still affect availability or integrity: accidental deletion or a power failure may be relevant. Assess the effects and applicable criteria rather than assuming only attacks count.

A practical allocation can have the supplier detect events in the covered environment, preserve logs and alert the customer. The customer supplies business-impact information; the parties develop the technical account together. The entity with the statutory duty classifies and reports the event itself or through an authorised person, with supplier support for updates and the final report.

Outsourcing reporting assistance does not remove the customer’s own statutory responsibility. If the supplier is independently covered, it may have a parallel duty for its own service. The customer’s report does not automatically settle that duty.

Personal data adds a GDPR assessment. A processor must notify its controller of a breach without undue delay, as UODO explains. CSIRT reporting does not replace the assessment of notification to Poland’s data protection authority or affected people. Align the security schedule and DPA so that they do not contain conflicting channels or deadlines.

How should vulnerability deadlines be set?

Consider severity, exploitation, exposure, affected functionality and available mitigations. A CVSS score can be one input; it does not reveal whether the component is used, whether the service is public, whether a fix exists or whether deployment will interrupt a critical workflow.

Agree information sources, triage, alerts, a remediation plan, target times and emergency measures. Set responsibilities for testing, maintenance windows and approval of changes. Record the effect if the customer postpones installation and agree temporary safeguards.

Avoid guaranteeing that every vulnerability can be removed within an identical time when some fixes depend on upstream vendors. The supplier can still commit to assessment, notification, a workaround and deployment once a suitable patch becomes available. Our secure-by-design contract guide connects that process with scope and acceptance.

What audit access is reasonable?

Audit rights should relate to the service. They should not automatically expose all supplier systems, source code or other customers’ data.

A staged approach starts with policies, existing reports and evidence, then explanations, and a technical review where that evidence is insufficient. The supplier may provide the scope of certification, appropriately limited test results, incident and continuity procedures, recovery-test evidence and a remediation plan.

Agree frequency, notice, confidentiality, auditor qualifications, access boundaries and costs. Provide an exceptional process for serious incidents or justified concerns. Contractual arrangements do not restrict a competent authority’s statutory powers.

Distinguish a KSC audit of an essential entity from a supplier audit agreed in a contract. An annual review at the development company’s expense is a negotiating request, not a universal statutory supplier duty. Where personal data is processed, Article 28 GDPR also affects audit cooperation.

Which subcontractors need customer control?

Focus on providers that host the system, monitor it, maintain important components, run backups or access data and privileged accounts. An office stationery supplier does not create the same service risk as the production hosting provider.

Agree disclosure, notification of changes, an objection period and a workable outcome when a change is not acceptable. Individual consent from every SaaS customer for every operational tool change may be difficult to deliver.

For personal data subprocessors, contractual flexibility has legal limits. Article 28(2) GDPR requires prior specific or general written authorisation. General authorisation also entails information about intended additions or replacements and an opportunity to object. A KSC schedule does not replace that process.

Check the supplier’s upstream promises too. A one-hour customer alert is hard to support if the hosting provider only has to contact the supplier on the next business day.

Connect continuity with the SLA

An SLA describes service commitments; a continuity process explains what happens during serious disruption. Agree availability, backups, recovery and communications together. A credit or penalty does not restore the service.

Explain two targets to the business:

• Recovery Time Objective (RTO): the target time for restoring operation.
• Recovery Point Objective (RPO): the acceptable data-loss window, expressed as time.

The customer needs to state the disruption and loss it can tolerate. The supplier needs to show what the agreed architecture and price can support, how recovery is tested and where it depends on other services.

Our SaaS SLA guide covers measurement and remedies. CRA security maintenance addresses a related product lifecycle, with different scope and application dates. A plan for one regime is not a substitute for assessing the other.

Can the supplier guarantee the customer’s full compliance?

That promise is usually too broad for the service. A supplier controls its tasks and agreed safeguards, not the customer’s entire organisation, supplier network or management decisions.

Replace a blanket guarantee with specific obligations: protecting access, delivering controls, alerting and cooperating on incidents, handling vulnerabilities, providing backups where in scope, supporting audits and managing important subcontractors.

The customer retains its own classification, registration, organisational security, reporting and management duties. A service agreement does not transfer its public-law status to the supplier.

Negotiate the liability cap, covered losses and exceptions separately. A promise to reimburse all administrative fines needs an assessment of its legal validity and connection with the supplier’s breach. It does not erase the authority’s penalty or the addressee’s responsibility. Article 473(2) of the Polish Civil Code also prevents excluding liability for damage intentionally caused to the creditor.

A hypothetical case: maintaining a healthcare system

This example is illustrative, not a client history. A private medical group has been assessed as covered by KSC. Its supplier maintains the application, updates, monitoring and second-line support. The customer buys cloud services directly and manages accounts and first-line support.

The proposed amendment makes the supplier responsible for whole-system compliance, one-hour alerts for every incident, 100% availability, all customer fines, unrestricted audits and consent for every subcontractor.

Rework it around the application, each party’s tasks and the cloud dependency. Define urgent event categories, round-the-clock contacts, logs, patch response, RTO, RPO, audit scope and liability for specific failures.

At 22:15 on Saturday, monitoring detects repeated login errors and attempts to retrieve documents. The supplier cannot yet confirm a disclosure. If the contract requires an alert for that suspicion within an hour, it should send the available facts, preserve logs and escalate immediately. The one-hour deadline is this contract’s assumption, not a rule imposed on every IT supplier.

The customer assesses business impact and user accounts; the cloud provider supplies facts from its layer. The medical group assesses KSC and GDPR notifications. The procedure names who can approve emergency access restrictions. Each participant then has a task it can actually perform.

Which Polish transition dates affect negotiations?

The Ministry of Digital Affairs’ timetable addresses entities meeting the criteria when the amendment entered into force:

• 3 October 2026: the KSC register deadline; check application duties and cases of registration by the authority.
• 3 April 2027: implementation of the new entities’ duties, including the information security management system, and connection to S46.
• 3 April 2028: the first mandatory audit for the relevant new essential entities. This is not a deadline for annual audits of every supplier.

Existing operators of essential services require separate treatment. Article 33(4) of the amending Act gives them six months to move to the new serious-incident reporting rules. It does not give them a year free of security and reporting duties. The transition also preserves the existing security management arrangements until the new ones are implemented.

For entities meeting the criteria later, calculate deadlines from the relevant event rather than copy these dates. Sector-specific rules may also matter. A customer can negotiate earlier contractual controls during its transition period, but the supplier needs to understand and price that earlier commitment.

Before signing the security amendment

Prepare your own service description, controls evidence, subcontractor list and proposed security schedule before the next customer amendment arrives. Negotiations then start from the way your team operates, making it easier to identify what is covered, what costs extra and what cannot reasonably be guaranteed.

For help aligning a Polish IT contract, SLA and incident process, see our technology legal services or discuss the supplier amendment with us.

Sources and further reading

• Ustawa o krajowym systemie cyberbezpieczeństwa, consolidated Polish KSC Act, including Articles 2, 5, 8, 11 and 16. Official text in Polish.
• Ustawa z dnia 23 stycznia 2026 r. o zmianie ustawy o krajowym systemie cyberbezpieczeństwa oraz niektórych innych ustaw, amending Act, Dz.U. 2026 poz. 252, including transition rules. In Polish.
• Directive (EU) 2022/2555, NIS2, official English text.
• Commission Implementing Regulation (EU) 2024/2690, official English text.
• Ministerstwo Cyfryzacji: Nowelizacja ustawy o krajowym systemie cyberbezpieczeństwa (KSC) - obowiązki podmiotów kluczowych i ważnych, Ministry guidance, in Polish.
• Centrum e-Zdrowia: Nowe przepisy KSC - sprawdź, czy dotyczą Twojego podmiotu, healthcare guidance, in Polish.
• Toolbox to improve ICT supply chain security, European Commission.
• UODO: Zgłaszanie naruszeń, breach notification guidance in Polish, and the GDPR, official English text.