Executive summary: What should companies do after NIS2 and KSC changes?
After NIS2 and the Polish KSC amendment, companies should translate legal obligations into an operating model: identify whether they are in scope, assign management responsibility, map critical services, verify suppliers, document risk treatment, strengthen backup, MFA, incident handling and keep audit evidence for decisions and controls. The biggest challenge is not the documentation itself, but the evidence of practical application: backup tests, supplier register, MFA reviews, training, incident procedure and management decisions. NIS2 and the amended KSC are a binding regime with specific deadlines.
- The practical question is not only whether the law applies, but which controls and evidence must be ready first.
- Management, IT, security, legal, procurement and business owners should work from one remediation plan.
- Virtline helps connect NIS2, ISO 27001, KSC, backup, incident response and supplier evidence into deliverable stages.
NIS2 audit
Classification, gap analysis, priorities and an evidence list for management and IT. Consistency of KSC, NIS2, ISO 27001, DORA and customer requirements in one programme.
NIS2 implementation
Controls, processes, owners and documentation organised into a realistic delivery plan.
SOC / SIEM / SOAR
Events, alerts, escalation and incident response organised as recurring evidence.
How does NIS2 readiness become an operating process?
Confirm legal scope, critical services and accountability. Separate urgent gaps from longer ISMS work. Give each action an owner, a statutory or risk-based deadline and acceptance evidence. Reviews after 60–90 days measure progress; they do not postpone protection or duties already due.
- Confirm the scope, status as an essential or important entity, and the services that must be protected.
- Check registration in the KSC list and the date your organisation first met the statutory criteria. The section below explains what to do after the registration window closed.
- Assign owners for risk, suppliers, incidents, business continuity, technical controls and reporting.
- Start with a register of critical services, an initial supplier register and a focused gap assessment.
- Assess NIS2/KSC gaps across risk, incidents, backup, suppliers, cryptography, MFA, access, documentation, training and testing.
- Plan the ISMS, incident procedure, MFA and privileged-account review, and a backup restore test.
- Collect supplier contracts and DPAs, certificates, security questionnaires, risk assessments and agreed actions.
- Management must decide which risks to reduce, accept, transfer to a supplier or close immediately.
- Name the reporting owner, set the first progress review and keep implementation evidence in one controlled location.
- Map remediation to ISO 27001 and KSC controls, then verify effectiveness through tests, training and current evidence.
NIS2 in Poland: the waiting stage is over
The amendment to the Act on the National Cybersecurity System implementing the NIS2 directive entered into force on 3 April 2026. From that moment on, the company should not ask whether it is worth waiting, but whether it knows its status, deadlines, obligations, owners and security vulnerabilities.
- 3 October 2026: the application deadline has passed for entities that met the conditions on 3 April 2026 and were not registered automatically.
- 3 April 2027: end of the adjustment period for implementing the required security measures.
- 3 April 2028: the first audit for essential entities that were not previously operators of essential services. Existing operators retain a cycle of at least once every three years from their last audit report; they do not automatically receive a new deferral.
- The following items need to be sorted: entity classification, risk analysis, suppliers, incidents, documentation and implementation evidence.
Priorities for a practical NIS2 programme
The programme should connect accountability, suppliers, continuity and evidence that controls work. Readiness checks cover risk management, incident handling, restore tests and management oversight.
- Management approves risk-management measures and oversees implementation. Liability depends on applicable national law and the individual’s role.
- Risks must be analysed, updated and assigned to owners, not just described in the policy.
- For an entity subject to the full reporting process: an early warning, a significant-incident notification and a final report; an intermediate report when requested. Determine applicable deadlines, exceptions and transitional rules under KSC Articles 11–12c and the organisation’s status.
- The supply chain requires an inventory, classification of ICT suppliers and periodic security assessment.
- Backup, business continuity and response procedures need to be tested, not just stored in files.
The most common error: there are documents, but there is no process
The riskiest pattern is policies, procedures and backups that exist only on paper. The auditor will ask about review dates, recovery tests, risk owners, activity reports and training evidence, not just a ready-made PDF document. Companies waste time when they start with standard documentation, ignore SaaS providers, do not test backups or do not have a decision-maker when risks are high.
- Backup is performed, but no one has checked the actual recovery of the key system and RTO/RPO time.
- Permissions, MFA and privileged accounts were implemented once, without recurring review.
- The register of SaaS providers exists fragmentarily, without classification of criticality and security requirements.
- Training and security tests take place sporadically or without records of attendance, findings and follow-up actions.
- The risk register has no owners, no deadlines for actions and no management decisions.
- Lack of clear qualification of the entity and postponement of entry into the list.
- Policies without owners, review dates and evidence of application.
- Incident procedure without contact numbers, roles, escalation thresholds and test.
Penalties and supervision: why you shouldn't wait to prepare
Article 34 NIS2 requires the maximum administrative fine to be at least EUR 10 million or 2% of worldwide annual turnover for essential entities and at least EUR 7 million or 1.4% for important entities — whichever amount is higher in each case. In Poland, Article 35 of the amendment defers the first imposition of the fines it specifies for two years after entry into force; the Ministry identifies 3 April 2028. This is not a general exemption from liability or an extension of compliance deadlines.
Self-identification
Determine whether the company is an essential or important entity, or a supplier subject to a customer's security requirements.
Evidence of implementation
An inspection plan, tests, decisions, reports and a corrective action schedule instead of just a set of documents.
Management supervision
Regular decision-making material for management: risks, budget, exceptions, incidents and programme progress.
What should a company check first?
The list below can be completed in 1-2 days as a quick readiness test. If the majority of the answers are we don't know, the company should formally designate a NIS2/KSC owner and launch a gap analysis.
- Do we know whether we fall within the scope of NIS2/KSC and whether we are an essential entity, an important entity or a supplier to one?
- Do we have an up-to-date risk analysis, review date and management decision on security measures?
- Does the incident procedure include people, telephone numbers, emails, reporting format and escalation thresholds?
- Are backups tested and does MFA work for privileged accounts, email, VPN, hosting, CRM and finance?
- Do we have a list of IT and SaaS providers with criticality classification, data, SLA and risk assessment?
What to prepare for registration and the management discussion
Self-registration and the KSC/NIS2 programme require information that usually cannot be collected on the final day. Prepare a package that connects legal classification with the real IT environment, critical services and business decisions.
- Business sector, size criteria, critical services and dependencies on regulated customers.
- Owners of processes, systems, risks, ICT suppliers and decisions to accept residual risk.
- A list of systems, data, locations, SaaS providers, privileged accounts and critical integrations.
- Technical-control status: MFA, backup, monitoring, EDR, vulnerabilities, logs, updates and segmentation.
- A management pack with high risks, budget, exceptions, time-bound priorities and proof of completion.
Dates that should be included in the management calendar
Dates were compared with the Ministry of Digital Affairs notice on 14 November 2026. For entities meeting the criteria when the amendment entered into force, the adaptation period ends on 3 April 2027; the first audit for newly covered essential entities is due by 3 April 2028. Status, date of coverage and exceptions must be established individually. S46 becoming available on 12 June 2026 was not the adaptation deadline.
- 13 April 2026: launch of the KSC List.
- 3 October 2026: the application deadline has passed for entities that met the conditions on 3 April 2026 and were not registered automatically.
- 12 June 2026: launch of the possibility of using the S46 system for new entities. S46 supports incident reporting, handling and cyber-threat information exchange; access and duties depend on the entity’s status.
- 3 April 2027: date of starting the use of S46 and implementing obligations for entities meeting the criteria on the date of entry into force of the Act.
- 3 April 2028: the first audit for essential entities that were not previously operators of essential services. Existing operators retain a cycle of at least once every three years from their last audit report; they do not automatically receive a new deferral.
What to check after the registration window
The self-registration window of 7 May–3 October 2026 has closed. Check whether registration was required automatically or by application and whether your organisation is registered. If a required application was not submitted, establish the next steps with the person responsible for compliance under the current rules; do not wait for another window. For organisations brought into scope later, determine the deadline from the date the qualifying conditions were met.
- Remove the assumption that NIS2 is a distant regulatory forecast from the programme plan.
- Replace a generic checklist with sector, size, critical-service and registration-path classification.
- Prepare a separate management pack covering high risks, budget decisions, owners, deadlines and evidence.
- Do not leave technology until the end: MFA, backup, monitoring, incidents and ICT suppliers need a trace in logs and reports.
- If the company serves regulated customers, include contractual requirements, ISO 27001 and DORA in the review.
Management oversight of cybersecurity
Business continuity, backups, incidents and risk management are not just technical tasks. The board should approve security measures, oversee implementation, receive regular reports, and undergo documented cybersecurity training. It is best when each decision has an owner, a deadline, business consequences and proof of implementation. Risk acceptance or transfer does not waive legal duties; outsourcing does not automatically transfer the entity’s responsibility.
- Risk decisions should be recorded in resolutions, minutes or formal acceptances of exceptions.
- The report to management should show control status, incidents, vendors, backup, MFA and outstanding activities.
- Management training should be repeated periodically and documented, just like employee training.
- The board should approve risk appetite, budget boundaries and temporary exceptions before implementation starts.
- Reports should separate legal obligation, operational risk and investment decisions so management can act.
- Does the company qualify as an essential entity, an important entity or a supplier covered by customer requirements?
- Which services, systems and suppliers are critical to business continuity.
- Which high risks do we accept temporarily and which ones do we close immediately?
- What budget do we allocate for MFA, backup, monitoring, EDR, documentation and training.
- Set a recurring management-review date and require every open exception to have an owner, deadline and documented risk decision.
Evidence that the auditor will look for
NIS2 and KSC require evidence that controls work in practice. An auditor will not stop at the security policy; they will look for records, reports, tests and named control owners. Before planning for NIS2 after the KSC amendment, verify the deadlines, technical scope, risk owner, acceptance evidence and operating model.
- A list of critical systems, data, locations, suppliers and process owners.
- MFA status, privileged accounts, exceptions and the date of the next access review.
- Backup test, RTO/RPO, recovery record and owners responsible for critical data.
- Incident process, reporting path, escalation, log sources and proof of an exercise or case review.
Backup and recovery
Backup recovery test with date, scope, result, RTO/RPO and corrective actions.
Access and identity
Privileged account and MFA review showing who approved access and when it will be checked again.
Monitoring and incidents
Alert timelines, escalation decisions, reporting records and lessons learned.
Scope, classification and ISMS
Sector and size assessment, critical services, risk register, policies, roles and review schedule.
Technical controls and tests
MFA, privileged accounts, backup, vulnerabilities, endpoints and dated control-test results.
Suppliers and management decisions
Supplier criticality, contracts, subcontractors, exit plans, risk decisions, budgets and remediation owners.
How does Virtline help companies prepare for NIS2/KSC?
Virtline combines technical auditing, cybersecurity, IT outsourcing and documentation. We turn recommendations into configurations, tests, processes and recurring records of completed work rather than leaving them in a report. We work across management, IT and process owners so that NIS2/KSC becomes an operational programme rather than a separate compliance binder. The initial discussion should confirm entity classification, critical services, the programme owner, backup status, suppliers, MFA, incident handling and the evidence available to management. Legal sources define the obligations, while the implementation project translates them into scope, owners, technical controls and maintained evidence. Primary sources and regulators’ guidance should be reviewed regularly because interpretations and national implementation requirements may change.
Focused gap analysis
We confirm whether the organisation is likely to be an essential entity, important entity or supplier under customer requirements. We map critical services, systems, suppliers, data and current security evidence before recommending tools.
Implementation programme
We turn findings into an evidence and accountability plan with owners, board decisions and implementation priorities. We help implement controls such as MFA, backup testing, monitoring, incident handling and supplier review.
Ongoing control operation
We prepare short evidence sets for management, customer audits, ISO 27001, NIS2 and DORA discussions.
SOC / SIEM / SOAR
Alert handling, incident response, escalation and records required for the compliance programme.
Primary sources and further reading
Check primary sources and regulator materials regularly because interpretations and national implementation requirements may change. A compliance programme should not rely only on marketing summaries.
Polish Ministry of Digital Affairs — key KSC deadlines
The official timetable, including the self-registration window from 7 May to 3 October 2026.
Open sourcePolish KSC amendment — Journal of Laws 2026 item 252
The official act of 23 January 2026 amending Poland's national cybersecurity system act.
Open sourcePolish national cybersecurity system act — consolidated text
Consolidated text predating the amendment: read together with Journal of Laws 2026 item 252 and subsequent amendments.
Open sourceRelated articles
Combine NIS2 work with practical technical areas: backup, MFA, monitoring and compliance.
Backup and data recovery
Restore and continuity tests provide evidence that recovery procedures work.
MFA
Control access to privileged accounts, email, VPN and critical services.
SOC / SIEM / SOAR
Monitoring, alerts, event correlation and support for the incident response process.
When to talk to an expert
Consulting makes sense when a company is unsure about classification, has a distributed IT environment, uses multiple SaaS services, serves regulated clients, or needs a plan that can be presented to the board.
- You need to determine whether the company is an essential entity, an important entity or a supplier covered by customer requirements.
- The organisation lacks designated risk and system owners or a maintained supplier register.
- You have no backup test, MFA review, incident procedure or evidence of training.
- You want to combine KSC with ISO 27001, DORA, contract requirements and real IT outsourcing.
- You need a defensible plan before customer questionnaires, supervisory questions or board budget decisions.
KSC and NIS2 controls to prove first
Start with controls that are easy to prove and hard to fake - privileged access, MFA, backup recovery, monitoring, incident reporting, supplier registers and documented management decisions.
ISO 27001 control alignment
Reuse ISMS controls, risk reviews and evidence discipline where they support KSC/NIS2 readiness.
Virtline audit experience
Review certification, audit history and delivery standards before choosing support for the deadline.
Cybersecurity control review
Verify privileged access, backup, monitoring, incident handling and supplier evidence with named owners.
Prepare the first NIS2/KSC discussion
The NIS2 programme should end every review with named owners, deadlines, evidence links and unresolved decisions. Otherwise the organisation has a document, but not an operating model.