KSC/NIS2 audit in 2026: who is in scope, what to test, and when

NIS2 and KSC: what is the audit criterion

NIS2 establishes a common EU framework for cybersecurity risk management, management-body accountability, incident reporting, and supervision. Member States implement those requirements in national law. Poland did so through the Act of 23 January 2026 amending the KSC, which entered into force on 3 April 2026.^[2][4]

A report should therefore not stop at the phrase "NIS2 compliant". A sound criterion identifies the specific KSC article, entity type, relevant service, annex, and any sector-specific act. Mapping to Articles 20, 21, or 23 NIS2 can then be added to explain the EU context. This order separates a legal obligation from a useful regulatory mapping.

As of 29 August 2026, the first self-registration period in the KSC Register is also relevant. For entities that met the criteria when the amendment entered into force and were not entered ex officio, the initial period runs until 3 October 2026.^[3] Before an organisation starts implementing controls, however, it must correctly determine whether it is an essential entity, an important entity, or outside the scope of those obligations.

Who is an essential entity and who is an important entity

Entity classification cannot be reduced to a headcount table. At least four questions must be answered.

First, what service is actually provided and which category in KSC Annex 1 or Annex 2 matches the entity? A business-classification code may help orientation, but it does not replace analysis of the real activity.

Second, does enterprise size matter for that category? Where the Act refers to size, the rules in Annex I to Commission Regulation (EU) No 651/2014 apply, including the rules for partner and linked enterprises.^[5] A shortcut such as "50 employees or EUR 10 million" can be wrong if group relationships are ignored.

Third, does an exception apply irrespective of size? The KSC contains categories whose status follows from the type of entity, importance of the service, or a special statutory qualification rather than a standard enterprise-size threshold.

Fourth, is there a regulatory decision or special provision changing the usual classification? The result should be documented. A useful audit artefact is a short memorandum identifying the legal basis, relevant annex item, data used for the size test, aggregation rules, exceptions, and final conclusion.

Public administration requires separate care. There is no rule that every local-government unit is automatically an essential entity. The Act identifies specific types of public entities and applies a particular implementation model to some of them. The audit has to be conducted at the level of the actual legal entity, not against a colloquial label for an entire public-sector group.

Timeline 2026-2028

For organisations affected from 3 April 2026, the following dates are particularly important:

• 3 April 2026 - the NIS2-transposition amendment entered into force;
• 13 April - 6 May 2026 - the first ex officio entries in the KSC Register;
• 7 May - 3 October 2026 - the first self-registration period for entities already meeting the criteria at the amendment date and not entered ex officio;
• 3 April 2027 - the principal deadline for Chapter 3 obligations for entities in scope on the amendment date, subject to transitional provisions;
• 3 April 2028 - for many essential entities that were in scope on 3 April 2026, the outer deadline for the first Article 15 audit, subject to prior status and audit history.^[2][3]

An entity that enters scope later calculates its own deadlines under Article 16 of the Act. It should not copy the calendar of an entity that was already in scope on 3 April 2026, because doing so leads either to a false sense of delay or to missing its own deadline.

What the audit tests: Article 8 as the core

Article 8 is the technical and organisational core. An essential or important entity must implement an information security management system in the information systems used in processes that affect service delivery and must manage cybersecurity risk systematically. Measures must be appropriate and proportionate to the risk and to the consequences an incident could create.^[1]

The audit should not be reduced to asking whether documents exist. It should test whether the organisation can demonstrate that the mechanisms operate in practice. A typical scope covers:

• security policies, risk methodology, a risk register, and risk-treatment decisions;
• secure acquisition, development, maintenance, and operation of systems, including vulnerability management and testing;
• physical, environmental, personnel, and access security;
• supply-chain security and continuity, contractual requirements, and supplier oversight;
• business continuity, disaster recovery, and evidence from exercises or tests;
• monitoring of systems and evaluation of control effectiveness;
• staff education, cyber hygiene, and management training;
• cryptography, secure communications, and strong authentication where required by risk;
• asset inventory, update management, threats, and vulnerabilities;
• detection, classification, handling, documentation, and reporting of incidents.^[1][4]

For certain public entities and specified higher-education and research units, the Act provides a special regime under Article 8(3) and Annex 4. An auditor should not simply apply the same control matrix used for an ordinary enterprise subject to Article 8(1).

Additional regime for certain digital services

DNS providers, TLD name registries, cloud providers, data centres, CDNs, managed service providers, managed security service providers, and other categories identified in the legislation may be subject to Commission Implementing Regulation (EU) 2024/2690. That regulation specifies NIS2 requirements for the listed entity categories.^[6]

In such an audit, Article 8 of the Act alone is not enough. The criteria matrix should also include the directly applicable EU implementing regulation, which descends to the level of concrete practices such as a plan for adopting email-security standards or an awareness-raising programme. This is a good example of why the phrase "NIS2 audit" without sector and legal basis is too imprecise.

Articles 9-13: organisation, documentation, and incidents

The audit scope does not end with the ISMS. The Act also regulates communication with the national cybersecurity system, documentation, vulnerability and incident handling, and reporting.^[1]

For documentation, the audit should test not only whether procedures exist but also version control, access, integrity, and retention. System logs, SOC records, tickets, test reports, and approved exceptions are often stronger evidence than a statement in a policy.

For a significant incident, the Act provides a reporting sequence including an early warning without undue delay and no later than 24 hours after detection, a notification no later than 72 hours, and a final report generally within one month of the notification.^[1][4] The audit should test not only the written process but also who starts the clock, who classifies the incident, who approves the notification, and whether decision-makers are reachable outside normal working hours. A procedure that operates only on working days between 8 and 16 does not meet a 24-hour deadline for an incident detected on a Friday evening.

Management cannot outsource accountability

The Act places particular emphasis on management responsibility. Assigning work internally to a CISO or IT team, or externally to a SOC provider, may transfer execution of tasks but does not eliminate the statutory responsibility of the head of the entity to ensure compliance.^[1]

An audit should therefore look for evidence that management:

• approves the direction of risk management and understands risk-acceptance criteria;
• makes budgetary and organisational decisions necessary to meet the requirements;
• receives meaningful reporting on risk, incidents, vulnerabilities, continuity, and remediation;
• has assigned people to direct cybersecurity tasks and defined their authority;
• completes the training required by the Act once in each calendar year and retains evidence of completion.^[1]

The Act does not impose one training duration or a specific certificate. Evidence should therefore not be an invoice for a course but documentation identifying participants, date, and substantive scope.

Competence and independence of people performing statutory tasks

The audit should also consider statutory requirements for persons performing specified functions. The Act includes, among other matters, criminal-record requirements for certain roles and detailed requirements for auditors conducting an Article 15 audit.^[1]

Independence is especially important. A person who currently performs tasks under Article 8 or Articles 9-13 in the audited entity, or who performed such tasks during the preceding year, cannot conduct the statutory Article 15 audit. This is much more precise than the vague statement that "an auditor must not know the organisation". Prior cooperation does not always disqualify an auditor, but its exact scope and timing must be examined.^[1]

The Article 15 audit: who and how often

The recurring obligation under Article 15 applies to essential entities. The security audit of the information system used to provide the service must be performed at least once every three years. An important entity does not acquire the same recurring cycle merely because it is an important entity. Supervisory authorities nevertheless have control powers and may order an external audit in circumstances defined by the Act.^[1][4]

The essential entity sends a copy of the audit report electronically to the competent authority within three business days of receiving it. Because the deadline is short, approval and secure-transmission arrangements should be defined before the engagement ends rather than after the report is delivered.^[1]

The statutory audit is not ISO/IEC 27001 certification. A certificate can provide valuable ISMS evidence, but it does not automatically replace the examination required by the Act.^[9] Nor is the Article 15 audit the same as the annual KRI audit. Each mechanism has its own criteria, scope, and legal effect.

DORA and Article 8i: an important sector exception

In financial services, obligations must not simply be stacked. DORA has applied directly since 17 January 2025. Article 8i of the Act regulates the relationship between DORA and parts of the national cybersecurity regime for specified entities in banking and financial-market infrastructure.^[1][7]

A checklist should therefore not be created by adding every requirement of the Act to every DORA requirement. The organisation must first be classified and the exact provisions that remain applicable identified, while functions governed by DORA are treated under the sector regime. The Polish Financial Supervision Authority highlights this relationship in its materials.^[8]

How to test effectiveness instead of document presence

A strong audit uses at least three kinds of evidence: a document, a technical configuration or system record, and actual human execution. An access-control policy does not prove that a former employee's account was disabled. A backup procedure does not prove that the organisation can restore a service. A SIEM report does not prove that someone analyses the alerts. ISO 19011:2026 and ISO/IEC 27007 provide the methodology for such an examination.^[10][11]

Examples of audit tests include:

• a sample of terminated employment relationships and time to revoke access;
• privileged-account samples including MFA and separation of duties;
• restore of a selected backup and comparison with required RPO and RTO;
• confirmation that loss of logs from a critical source is detected;
• tracing a vulnerability to a remediation task, owner, deadline, and approved exception;
• tracing an alert to incident classification and a reporting decision;
• review of a key-supplier contract, security requirements, and exit scenario;
• a controlled detection test where separately agreed and authorised.

This approach usefully combines the KSC audit with an IT security audit, vulnerability scanning, penetration testing, and SOC monitoring, but those services remain separate evidence sources. A single scan or penetration test should not be presented as a complete compliance audit. NIST CSF 2.0 can help organise security functions, but it is not a legal criterion in Poland.^[12]

Common mistakes

1. Auditing against an old text of the Act or against NIS2 alone. In either case, a report may look professional while failing to test the law actually applicable in Poland on 29 August 2026.
2. Classifying the entity from a business code or headcount without analysing actual services, enterprise relationships, and statutory exceptions.
3. Treating documentation as compliance. The Act requires a working management system and risk-proportionate measures. A document describing a process without evidence of execution is only a declaration.
4. Treating an important entity as though it had the same recurring Article 15 audit obligation as an essential entity.
5. Ignoring specific legislation, especially Regulation 2024/2690 for specified digital services and DORA in financial services.
6. Auditing one's own work through a person covered by the statutory independence restriction.

What the report should contain

A report should allow a competent person outside the audit team to reconstruct the basis for the conclusion. In practice this means:

• entity identification and legal classification;
• legal-status date and audit criteria;
• scope of systems, services, locations, processes, and suppliers;
• sampling method and audit limitations;
• each finding linked to a specific requirement and evidence;
• separation of legal non-compliance from technical risk;
• remediation priority, owner, and due date;
• definition of the evidence required to close the finding;
• a protected technical appendix for details that should not be widely distributed.

A red and green table alone is not a good report. Management needs to understand what decision is required, while administrators need to know exactly what must change and how closure will be verified.