Registering an NIS2-covered entity — what goes in item 16?

22 September 2026

Management receives notice of entry in Poland’s National Cybersecurity System register and a request to complete details. One field asks about an external-provider contract. Item 16 concerns an existing contract; it does not require one to be signed. The entry records contract status, while incident-handling capability depends on people, process and prompt response. Learn what to enter and when a provider helps.

Key information:

  • No contract is also an answer —the form must reflect the actual situation.
  • Three delivery models —tasks are performed by an internal team, a provider or both together (Article 14 of Poland’s National Cybersecurity System Act).7.
  • A contract describes a real service —the activities, roles and procedure for requesting support matter.
  • Management retains responsibility —outsourcing tasks does not transfer statutory obligations (Article 8c of the KSC Act).8.
  • Details must be kept up to date —a change or termination of cooperation requires the entry to be updated within 14 days (Article 7c(3) of the KSC Act).9.

What is the KSC Register, and why has the organization received a notice?

A notice is sent to an organization that the authority considers subject to the Act but that is not yet registered. The KSC Register—formally the Register of Essential and Important Entities—collects information on entities covered by Poland’s National Cybersecurity System. Some companies register themselves; others are notified of registration by the authority.1.

Note the two separate procedures and deadlines—one of the points that needed clarification in the original article:

1. Self-registration

The entity submits its own application for registration. Under Article 7c(1) of the KSC Act, the application must be submitted within 6 months of meeting the criteria for classification as an essential or important entity2. Self-registration opened on 7 May 2026. For entities that already met the criteria on 3 April 2026, when the amendment entered into force, the deadline is 3 October 2026.3 For entities that become subject to the Act later—for example by crossing size thresholds or changing their business profile—the period runs from the date they meet the criteria, not a fixed calendar date.

2. Registration by the authority

This applies to four categories of entities expressly listed in Article 7a(2) of the KSC Act: telecommunications operators, trust service providers, public entities and existing operators of essential services4. The Minister of Digital Affairs began registering these entities on 13 April 2026.5 In this procedure, the entity does not submit its own application. The Minister of Digital Affairs serves a registration notice and requests the missing information within 6 months of service of the request (Article 7b(1)–(2) of the KSC Act).6.

This second procedure matches the opening scenario: a registration notice and request reach management without any prior application by the organization.

The register holds information, while System S46 (Article 46(1) of the KSC Act), also known as S46 Cyber Hub, supports ongoing communication and reporting.10 The application is submitted by the entity’s head or an authorized person and requires a qualified electronic signature, trusted signature, personal signature or qualified electronic seal (Article 7c(6) of the KSC Act). It also includes the head’s declaration made under criminal liability under Article 233 § 6 of the Criminal Code (Article 7c(5) of the KSC Act). IT gathering the information does not replace formal authorization, so the signing procedure should be established in advance.

Registration is also declaratory (Article 7d(5) of the KSC Act): the obligations in Chapter 3—an information security management system, incident handling and reporting, and audits—apply from the date the Article 5 criteria are met, not the registration date. NIS2 registration concerns information; implementing the obligations has its own timetable.

What exactly does item 16 cover?

Item 16 corresponds to Article 7(2)(16) of the KSC Act and concerns one fact: whether the organization has contracted a managed security service provider to perform tasks under Articles 8 and 11. The form asks for the provider’s name, registered office and correspondence addresses, telephone number and email address.

The two provisions referenced cover different obligations:

  • Article 8 of the KSC Act —implementing and maintaining an information security management system (ISMS), including risk assessment, documentation, incident response procedures and organizational and technical measures. Article 8(2) sets out the detailed ISMS areas.
  • Article 11 of the KSC Act —incident handling and reporting, including an early warning within 24 hours of detecting a significant incident, an incident notification—usually within 72 hours—and a final report, generally within one month of completing incident handling (Article 11(1)(4), (4a) and (4c)).

Item 16 in the KSC Register describes the situation on the application date. The scope entered should match what the provider actually does. A consultancy-only agreement should not be described as full event handling, while a technical monitoring contract requires checking what NIS2 requires of security monitoring. A mismatch between description and reality usually becomes apparent during the first significant event.

Does every NIS2 entity need an external cybersecurity company?

An external provider is not a prerequisite for compliance. Many organizations look for an NIS2 cybersecurity company, while the Act uses the narrower term „managed security service provider,” defined in Article 2(4j) of the KSC Act. Article 14 of the KSC Act allows tasks under Article 8 and incident-related provisions to be performed internally or entrusted to a managed security service provider; in practice, organizations combine both approaches. The chosen model must ensure that all obligations are fulfilled. This flexibility applies equally to essential and important entities.

Three models for performing the tasks

The table compares the three options permitted by Article 14 of the KSC Act to help select a model appropriate to the organization’s size and maturity.

Model Who actually performs the tasks Advantages Limitations and risks When it works best
Internal The organization’s own IT/security team, without an external provider Full control over processes and data; no provider dependency; knowledge stays in the organization Requires permanent staffing, including out-of-hours duty, and ongoing skills maintenance; a 24/7 team can be expensive to maintain Large organizations with an established, mature security department and a real capacity to cover duty shifts
External A managed security service provider operating under a contract covering tasks under Article 8 or Article 11 Rapid access to specialists and established processes; predictable, usually subscription-based costs; easier scaling of availability, such as a 24/7 SOC The organization must retain oversight and decision-making capability; service quality depends on contract precision and actual delivery; listing a provider in item 16 can be mistaken for paper compliance without a real service Entities without an internal security team or needing to fill specific skills gaps quickly, such as CSIRT notification handling
Hybrid Tasks are divided between the internal team, such as IT, and an external provider according to the roles set out in the contract Combines the organization’s operational control with specialist provider support; flexibly matches scope to actual skills gaps The contract must specify who classifies an incident, who escalates it and who approves the notification—unclear roles are the most common source of disputes during an incident Organizations with capable IT departments but without specialist security skills or out-of-hours duty capacity—the most common model in practice

Which model does an organization without a security team choose?

A typical situation is a public entity notified of registration by the authority. It has a capable IT department but lacks security specialists and out-of-hours coverage. It chooses a hybrid model: IT retains operational responsibility, while the provider maintains the incident register and supports event classification, escalation and reporting. The contract defines roles, contact times, reporting and data updates.

Is a simple contract enough?

A contract can cover a narrow set of tasks and still be valid, but it must describe a service actually delivered. Problems arise when a document lists statutory obligations but nobody on the other side has an assigned role. Compliance is demonstrated by fulfilling obligations; the document merely describes them.

A cybersecurity contract becomes useful when it names activities and assigns them to specific people. Its scope is easiest to assess against the step-by-step cyberattack response process: detection, containment, eradication of the cause and service restoration. After the event, there is evidence of delivery: registers, reports and notification confirmations.

What basic scope makes sense?

Basic NIS2 incident handling includes:

  • Receiving reports from designated individuals.
  • Classifying the event as an incident or a technical fault.
  • An incident register maintained or supervised by the provider.
  • Supporting notifications to the relevant Computer Security Incident Response Team (CSIRT). In practice, Article 11 of the KSC Act sets reporting timeframes: an early warning within 24 hours, incident notification within the subsequent window and a final report generally within one month.
  • Escalation to management and contact persons.
  • A periodic report with recommendations for improvement.

In our work, the basics take the most time: who in the organization can request support, who classifies an event as an incident and who approves the notification. We document this with the client before the first event, because an incident is no time to establish authority.

What should a provider contract contain?

The contract should define entrusted activities, roles on both sides, support availability and how work is documented. The Act does not prescribe an official contract template, so the eight areas below are organizational good practice, not a statutory checklist. The last one—an audit trail after cooperation ends—is easily overlooked, and its absence often emerges only when changing providers.

Eight areas a good contract covers

Minimum contract elements and why they matter:

Area What to describe Why it matters
Scope of tasks Activities under Article 8 or Article 11, and exclusions Demonstrates that the service is real
Roles Who assesses, who decides and who approves notifications Prevents disputes during an incident
Availability Hours, emergency channels, SLA and escalation Must match the risk profile
CSIRT notifications Who prepares the data, who submits it and where confirmation is stored Control over the reporting obligation
Register and documentation Records, location, permissions and retention A post-incident audit trail
Information security Confidentiality, access and subcontractors The provider learns about the organization’s vulnerabilities
Reporting Frequency, recipients and recommendations Management oversight of the service
Changes and termination Updating the KSC Register entry within 14 days under Article 7c(3), returning data and handing over documentation Continuity when changing providers

How much availability is actually needed?

Availability follows risk analysis and the importance of the services, so not every contract must provide round-the-clock duty. The KSC Act differentiates reporting deadlines by entity category and incident type (Article 11). The general timeframes—an early warning within 24 hours, notification and a final report generally within one month—derive from Directive 2022/2555. Where a service includes round-the-clock oversight, availability requirements must support that commitment.

CSIRT reporting needs a separate agreement on who prepares the data, who submits it and where confirmation is stored. If a contract already exists, compare its terms with the tasks listed in the Register before completing the form. At VigilHorizon, we start with that review: read the scope, check who requests support and only then discuss gaps.

What does the provider not take over?

A contract delegates activities; statutory obligations remain where they were. The entity’s head retains responsibility even when an external company performs the tasks. Article 8c of the KSC Act states this explicitly8, linking responsibility to the management role regardless of who performs the tasks, including where duties are assigned to another person with their consent. In practice, while the Incident Response team stops a cyberattack step by step, decisions to disconnect a system or notify customers remain within the organization.

The entity primarily retains:

  • Management responsibility for fulfilling obligations (Articles 8c and 8d of the KSC Act).
  • Implementation of an information security management system (Article 8 of the KSC Act).
  • Business decisions about acceptable risk.
  • Completeness and currency of information in the register.
  • Obligations outside the contract, where the contract covers only a selected scope.

That is why, when discussing service scope, our first question is who does what in the first few minutes after an event is noticed. Once both sides have documented the answer, the form entry starts to describe a real way of working.

How do you choose a cybersecurity service provider?

Assess an NIS2 cybersecurity provider by how it works day to day. An external cybersecurity consultant suits organizations needing decision support and orderly documentation while performing continuous oversight internally.

Criteria that genuinely distinguish providers

What to assess in a provider:

  • Incident experience and knowledge of KSC and NIS2 requirements.
  • Clear processes with documented escalation and role allocation.
  • Cooperation with CSIRTs and the client’s IT department.
  • Secure processing of incident data.
  • Auditability of reports and a documented service exit plan.

Check two points separately. The first is criminal-record verification for personnel authorized to perform tasks under Articles 8 and 11; organizations often remember this only after signing. The second concerns scale: before commissioning continuous oversight, understand what a 24/7 SOC is and why monitoring alone is not enough.

Checklist before completing item 16

Before updating the KSC Register, conduct a brief review of the actual situation. The aim is to ensure that item 16 describes what really happens in the organization.

Check the following:

  1. Has the organization contracted a managed service provider?
  2. Which tasks under Article 8 or Article 11 does the contract cover?
  3. Are the provider’s details complete and current?
  4. Do contact persons know how to request support?
  5. Does the contract cover the register, escalation and event reporting?
  6. Who is responsible for updating the entry when cooperation changes?

Resolve unanswered questions in the provider contract before completing the form. Any subsequent change to information under Article 7(2)(1)–(18), including provider details in item 16, requires an application to amend the entry within 14 days of the change (Article 7c(3) of the KSC Act)9. Missing this deadline may lead to verification by the authority (Article 7k) and a financial penalty (Article 73(1)(1)). Clear roles and documentation provide the basis for an NIS2 compliance audit and preparing the organization for inspection.

Item 16 is not a place to name an arbitrary company. It should show who actually performs specific tasks for the organization and on what basis.

Where should you start preparing the entry?

The form completes registration. Incident readiness is decided elsewhere: by the people who will classify the event, the procedure they know by heart and how quickly they can respond. Before listing a provider, read your contract as someone looking for a telephone number in the middle of the night would. If it does not say who makes a decision and who carries it out, the entry may be formally correct but operationally empty.

When there is uncertainty, we start by discussing the actual situation: a readiness review, an assessment of the existing contract’s scope or preparation for round-the-clock managed incident handling. We then explain what can be outsourced and what remains within the organization.

Frequently asked questions (FAQ)

Does every essential or important entity have to contract a cybersecurity company?

The obligation is to perform the tasks under Articles 8 and 11. The organization chooses its delivery model under Article 14 of the KSC Act. A provider is listed on the form only when the contract actually covers tasks under Article 8 or Article 11.

What goes in item 16 if the organization has no external provider?

Report the absence of a contract truthfully rather than listing a hardware maintenance company. Check how to indicate this in the current S46 instructions available after signing in at wykaz-ksc.gov.pl, or ask NASK support.

Can an ordinary IT company be listed as a cybersecurity provider?

The contract’s scope and the statutory definition in Article 2(4j) of the KSC Act determine this. Computer support without tasks under Article 8 or Article 11 does not make an IT company a managed security service provider.

Can a provider be engaged only to maintain the register and handle notifications?

A scope this narrow is permitted if precisely described in the contract. The remaining tasks stay with the organization and need their own owners.

Can a provider report incidents on the organization’s behalf?

This requires authorization, access to System S46 and agreement on who approves the notification. A register entry alone grants no such permissions.

Does naming a provider mean NIS2 compliance?

The entry informs the authority about a contract; it does not establish that obligations have been implemented. Compliance is demonstrated through documentation, procedures and evidence of operation. Registration is declaratory under Article 7d(5) of the KSC Act.

When should provider information in the KSC Register be updated?

After every change to reportable information, within 14 days of the change (Article 7c(3) of the KSC Act)9. This also includes ending cooperation and changing contact addresses.

Learn more

Legal position as of 14 September 2026. This article is based on the Act of 5 July 2018 on the National Cybersecurity System (consolidated text, Journal of Laws 2026, item 20), amended by the Act of 23 January 2026 amending the National Cybersecurity System Act and certain other acts (Journal of Laws 2026, item 252), which entered into force on 3 April 2026 and implements Directive (EU) 2022/2555 of the European Parliament and of the Council (NIS2). Referred to below as the „KSC Act” or „KSC.”

Main sources:

  1. System S46 —the „Self-registration” and „Introduction to the KSC Register” instructions: gov.pl/web/system-s46 (subpages: gov.pl/web/system-s46/wykaz-ksc, gov.pl/web/system-s46/s46-cyber-hub); application portal: wykaz-ksc.gov.pl/login.
  2. Ministry of Digital Affairs —obligations of essential and important entities and current Q&A: cyber.gov.pl/faq; source document „KSC Amendment Q&A” (PDF, gov.pl/attachment); announcements: gov.pl/web/cyfryzacja—launch of self-registration, gov.pl/web/cyfryzacja—who is covered, gov.pl/web/cyfryzacja—entity obligations.
  3. Current text of the KSC Act —particularly Article 7, including Articles 7a, 7b, 7c, 7d and 7j, and Articles 8 and 11: isap.sejm.gov.pl (consolidated text, Journal of Laws 2026, item 20) and dziennikustaw.gov.pl (amending Act, Journal of Laws 2026, item 252, for provisions introduced or amended by it, including Articles 7a–7b).

Footnotes:

  1. The KSC Register as an application within System S46— https://www.gov.pl/web/system-s46/wykaz-ksc.
  2. Article 7c(1) of the KSC Act—consolidated text, Journal of Laws 2026, item 20: https://isap.sejm.gov.pl/isap.nsf/DocDetails.xsp?id=WDU20260000020.
  3. Self-registration period, 7 May–3 October 2026—”Launching self-registration” announcement: https://www.gov.pl/web/cyfryzacja/nowelizacja-ustawy-o-krajowym-systemie-cyberbezpieczenstwa-ksc–uruchamiamy-samorejestracje-w-wykazie-podmiotow-kluczowych-i-podmiotow-waznych-sprawdz-jak-dokonac-wpisu.
  4. Article 7a(2) of the KSC Act—amending Act, Journal of Laws 2026, item 252: https://isap.sejm.gov.pl/isap.nsf/DocDetails.xsp?id=WDU20260000252 (PDF: /external/api.sejm.gov.pl/eli/acts/DU/2026/252/text.pdf).
  5. Registration by the authority began on 13 April 2026—”Who is covered” announcement: https://www.gov.pl/web/cyfryzacja/nowelizacja-ustawy-o-krajowym-systemie-cyberbezpieczenstwa-ksc—kogo-obejmuje.
  6. Article 7b(1)–(2) of the KSC Act, six-month deadline from service of the request—amending Act, Journal of Laws 2026, item 252: https://isap.sejm.gov.pl/isap.nsf/DocDetails.xsp?id=WDU20260000252; descriptive confirmation: https://www.gov.pl/web/cyfryzacja/nowelizacja-ustawy-o-krajowym-systemie-cyberbezpieczenstwa-ksc—kogo-obejmuje.
  7. Article 14 of the KSC Act—consolidated text, Journal of Laws 2026, item 20: https://isap.sejm.gov.pl/isap.nsf/DocDetails.xsp?id=WDU20260000020.
  8. Article 8c of the KSC Act—consolidated text, Journal of Laws 2026, item 20: https://isap.sejm.gov.pl/isap.nsf/DocDetails.xsp?id=WDU20260000020.
  9. Article 7c(3) of the KSC Act, 14-day deadline for updating details—consolidated text, Journal of Laws 2026, item 20: https://isap.sejm.gov.pl/isap.nsf/DocDetails.xsp?id=WDU20260000020.
  10. System S46 / S46 Cyber Hub, Article 46(1) of the KSC Act— https://www.gov.pl/web/system-s46/s46-cyber-hub.

Not sure which plan is right for your business?
Complete a short questionnaire

Complete the form and we will help you select monitoring, incident handling or availability support for your organisation. We will agree the scope and service conditions before work begins.

Tell us about your IT environment

Fields marked * are required.

Additional interests

The controller of your personal data is VigilHorizon sp. z o.o. For personal data enquiries, contact: privacy@vigilhorizon.pl

We process data from correspondence we receive to respond to enquiries. The legal basis is Article 6(1)(b) GDPR when we take steps at your request before entering into a contract with you, or Article 6(1)(f) GDPR — our legitimate interest in handling correspondence, including with representatives of organisations.

We will send your enquiry only when you select Send enquiry.