NIS2 and KSC 2026: cybersecurity checklist for companies

NIS2 and the Polish amendment to the Act on the National Cybersecurity System (KSC) are no longer distant regulatory topics. For many organizations in Poland, 2026 means checking whether the company falls under the new obligations and then organizing cybersecurity in practice: access, backups, monitoring, incident procedures and management responsibility.

This material is not legal advice. It is a practical IT checklist for owners, boards, operations directors and people responsible for technology. It helps assess whether the organization has the operational foundations needed for further KSC/NIS2 analysis.

What changed in 2026

According to information published by the Polish Ministry of Digital Affairs, the KSC amendment entered into force on 3 April 2026. From that date, deadlines started running for entities covered by the new rules.

Key dates:

3 April 2026 - entry into force of the KSC amendment,
7 May 2026 - launch of self-registration in the KSC register,
3 October 2026 - deadline for submitting the registration request for entities that must self-register,
3 April 2027 - deadline for implementing obligations for key and important entities that met the criteria on the date the act entered into force,
3 April 2028 - deadline for the first mandatory cybersecurity audit for key entities.

Official information should always be checked at the source:

Who may be affected by KSC and NIS2

The KSC amendment replaced the previous distinction between operators of essential services and digital service providers with key entities and important entities.

In practice, companies should check:

whether they operate in a sector listed in the act,
whether they meet size criteria,
whether they are entered into the KSC register by authority or must self-register,
whether technology suppliers support critical processes,
whether digital services are important for customer or market continuity.

This analysis should be carried out with a lawyer or compliance advisor. IT should not decide legal qualification on its own. IT should prepare facts: systems, processes, suppliers, contracts, integrations and safeguards.

Why this is operational, not only legal

The biggest mistake is treating KSC/NIS2 as a document to complete. In practice, the regulations affect the daily way technology is managed.

If a company does not know who has production access, when backups were last tested, where alerts go or who makes decisions during an incident, the problem is not formal. It is operational risk.

KSC/NIS2 push companies to organize areas that should be under control anyway:

risk management,
supplier oversight,
business continuity,
incident response,
access security,
system documentation and ownership,
periodic tests and audits.

Cybersecurity checklist for companies

This list does not replace a compliance audit. It gives a practical starting point for organizations that want to see the biggest operational gaps quickly.

1. Cybersecurity owner and responsibility

Start by defining who is actually responsible for cybersecurity.

Check:

whether the board or owner has assigned responsibility for IT and cybersecurity,
whether a simple RACI model exists,
whether technical people know when to escalate an incident to business,
whether the company has emergency contacts for IT partner, hosting, system supplier and domain operator,
whether responsibility for applications, website, infrastructure and workstations is not split across suppliers without coordination.

No process owner means that during an incident the company loses time deciding who can decide.

2. Inventory of systems and critical processes

You cannot secure an environment nobody has described.

Prepare at least:

list of business applications,
list of websites, shops, client panels and landing pages,
list of databases and backup locations,
list of SaaS suppliers,
list of domains, certificates and hosting accounts,
list of integrations with CRM, ERP, payments, email, analytics and automation,
identification of systems critical for sales, customer service, finance and operations.

Practical test: if the main technical person leaves tomorrow, does the company still know where repositories, servers, domains, admin passwords, backups and documentation are?

3. Accounts, permissions and MFA

In many companies the largest risk is not an advanced attack, but excessive access.

Check:

whether all administrative accounts use MFA,
whether former employees or suppliers still have permissions,
whether shared accounts have been limited or replaced with named accounts,
whether production access is granted only to people who need it,
whether onboarding and offboarding include access management,
whether permissions are reviewed at least quarterly.

The simple rule: fewer permanent privileges, more control and a clear audit trail.

4. Backups and recovery tests

A backup without a recovery test is an assumption, not protection.

The company should know:

which systems are backed up,
how often backups run,
how long copies are retained,
who can restore data,
how long recovery of a critical system takes,
whether there is a copy protected from accidental deletion or ransomware,
when the last recovery test happened.

Define two parameters:

RPO: how much data the company can lose,
RTO: how quickly the system must return.

Without these numbers, continuity planning is too vague.

5. Monitoring, logs and alerts

The organization should detect problems before customers do.

Minimum monitoring:

uptime of website and applications,
5xx errors and critical application errors,
server and database resource usage,
failed login attempts,
administrative permission changes,
expiring certificates and domains,
backup success,
security alerts from cloud, hosting and SaaS tools.

Where the alert goes is equally important. An alert sent to an inbox nobody reads does not reduce risk.

6. Incident procedure

An incident is not the time to design the process.

A minimal incident runbook should define:

what counts as a critical incident,
who receives the report,
who assesses impact,
who decides about rollback, account blocking or disconnecting integrations,
how internal communication works,
who communicates with clients or partners,
which logs and evidence are preserved,
how the event is documented,
when postmortem happens.

A good runbook shortens the time from chaos to decision.

7. Application and website security

KSC/NIS2 often starts with compliance, but practical risk appears in code, configuration and deployment process.

Check:

whether repositories have owners and protected permissions,
whether CI/CD pipelines do not store secrets in code,
whether dependencies are updated,
whether critical paths have tests,
whether rollback exists,
whether forms, admin panels and APIs are monitored,
whether the website has current security headers,
whether the application has rate limits and abuse protection.

If the company develops an existing application, combine KSC/NIS2 preparation with technical debt reduction. We cover this in: Maintaining and developing an existing application.

8. Suppliers and contracts

Modern IT is a supplier chain: hosting, cloud, SaaS, software house, web agency, email provider, analytics tools, CRM and helpdesk.

Prepare:

list of suppliers supporting critical processes,
description of data they can access,
business owner of each contract,
SLA requirements and response times,
escalation procedures,
documentation and access handover rules,
contingency plan if a supplier becomes unavailable.

The most risky model is one where every supplier owns a small fragment but nobody owns the whole.

30/60/90-day plan

If KSC/NIS2 is just reaching the management table, do not start with a multi-month project. Start by organizing facts and reducing the highest risks.

First 30 days: regain control

check whether the company may fall under KSC/NIS2,
prepare lists of systems, suppliers, domains, integrations and data,
enable MFA on administrative accounts,
remove unnecessary access,
confirm backups exist and are monitored,
monitor critical services,
appoint the process owner on the business side.

Days 31-60: procedures and quick fixes

perform a backup recovery test,
prepare a basic incident runbook,
organize supplier access,
describe RTO/RPO for critical systems,
check logs and alerts,
remove urgent vulnerabilities in the website and applications,
define a monthly IT risk report.

Days 61-90: stabilize the model

build a quarterly cybersecurity roadmap,
connect KSC/NIS2 requirements with the IT budget,
introduce cyclic permission reviews,
define standards for new systems and suppliers,
plan an audit or compliance review,
prepare a management report: risks, status, decisions and costs.

Common mistakes

1. Waiting until the final deadline

Formal deadlines are one thing. Preparing documentation, access, backups, monitoring and procedures can take months.

2. Treating cybersecurity as an IT cost

Cybersecurity protects continuity of sales, service, production and finance. It is business risk, not only a technical topic.

3. No single responsible side

If an application is owned by a software house, the website by an agency, hosting by an administrator and email by another supplier, the company needs coordination.

4. No evidence

In many organizations safeguards “exist”, but nobody can prove when a backup was tested, who approved access, when permissions were reviewed or who received an alert.

Summary

NIS2 and KSC in 2026 are not only formal topics. They are a good moment to check whether the company controls cybersecurity basics:

responsibility owner,
list of systems and suppliers,
secure accounts and MFA,
backups with recovery tests,
monitoring and logs,
incident procedures,
organized supplier model.

If you need a partner who can move from checklist to operational changes, see IT Partner.