NIS2 and penetration testing in the Czech Republic: what applies to your Czech entity

Yes, if the Czech subsidiary provides a regulated service. Act No. 264/2025 Coll. applies to persons established in the Czech Republic (Section 1(2)) and attaches to the Czech entity that provides the service, not to its owner. A regulated service is a service that meets at least one criterion of Decree No. 408/2025 Coll., or one that NÚKIB designates by decision; whoever provides it is the regulated service provider.

A Czech subsidiary is a Czech legal person; a parent in Munich, Vienna, or Boston doesn’t change that, and the Act contains no exemption based on where the owner is established. Under Article 26(1) of NIS2, an entity falls under the jurisdiction of the Member State in which it is established. The owner comes up once: after registration, you report the ownership structure to NÚKIB as part of the supplementary data (Section 11(1)(b)).

A parent company’s registration with its home regulator (under the German BSIG, for example) therefore does not replace the notification of a Czech regulated service to NÚKIB. The Act binds every person established in the Czech Republic whose service meets the conditions of Section 4(1) (Sections 1(2) and 6(1)), and it contains no provision that recognizes a registration made abroad. Each Member State keeps its own list of entities (Article 3(3) of NIS2).

The one cross-border carve-out, Section 18(3) with Section 54(3) and (4), covers DNS service providers, TLD name registries, domain name registration services, cloud computing, data center and content delivery network services, managed service providers and managed security service providers, online marketplaces, online search engines, and social networking platforms whose main establishment is in another Member State. Main establishment follows Article 26(2) of NIS2: where decisions on cybersecurity risk-management measures are predominantly taken, failing that where cybersecurity operations are carried out, failing that the largest EU establishment by headcount; Section 54(5) of the Act reads the same. The carve-out narrows their Czech obligations to the measures in Section 18(1) and limits NÚKIB’s inspections to requests from the home regulator. It does not remove the obligations, and it does not apply to a factory, warehouse, development center, or sales subsidiary.

A registered branch (“odštěpný závod” in Czech) of a foreign company has no legal personality of its own, and the Act says nothing about branches. The Czech law firm HAVEL & PARTNERS, in an analysis published in March 2026, reads the Act as addressing the foreign company itself, so the whole company’s size counts.

Company size is measured across the whole group, not just the Czech entity. Size is assessed under Commission Recommendation 2003/361/EC, and the Recommendation does not stop at borders: a parent or sister company in Germany, the Netherlands, or the United States counts exactly as a Czech one would. Partner enterprises (25% to 50% of capital or voting rights) are added in proportion to the holding; linked enterprises (more than 50%, or control by other means) are added in full. Size matters because Section 4(1)(b) of the Act refers to a medium-sized or large enterprise within the meaning of the Recommendation. A group that thinks of its Czech plant as a small local entity is looking at the wrong number.

Headcount alone is enough; exceeding one financial ceiling alone is not. An enterprise is medium-sized at 50 or more employees, or when it exceeds both EUR 10 million in turnover and EUR 10 million in balance sheet total; it is large at 250 or more employees, or when it exceeds both EUR 50 million in turnover and EUR 43 million in balance sheet total. A company with 60 employees is a medium-sized enterprise even with turnover under EUR 10 million. NÚKIB runs a calculator on the NÚKIB Portal; the calculator does not add partner and linked enterprises, so you have to add those yourself.

Section 7(c) of the Act adds one exception to the size test: a person whose technical assets are wholly separate from the technical assets used to provide the regulated service is not treated as a partner or linked enterprise (NÚKIB’s translation says “connected enterprise”). Whether that covers a foreign parent depends on the facts, not on where the parent sits: a shared Active Directory, ERP, network, or group IT service means shared technical assets.

There are two ways into the register. Either you assess the conditions of Section 4(1) yourself and notify the service, which NÚKIB calls self-identification, or NÚKIB registers the service by its own decision, ex officio (Section 5). By February 8, 2026, 4,825 organizations had notified a regulated service to NÚKIB, against roughly 6,000 that NÚKIB had long expected to fall under the Act (NÚKIB, February 11, 2026).

One of two: the Act sorts the provider, not each service, into the higher obligations regime (Section 8(1)) or the lower obligations regime. Section 14(1) lists 14 organizational and 11 technical measures for the higher regime; Section 14(2) lists 13 measures for the lower one. The detail sits in Decree No. 409/2025 Coll. for the higher regime and Decree No. 410/2025 Coll. for the lower.

NÚKIB’s rule of thumb: large enterprises in selected sectors fall into the higher regime, medium-sized ones into the lower. The exceptions matter. DNS, TLD registries, and public administration are assessed separately, and internet service providers are regulated at any size, with size deciding only the regime. A service registered by NÚKIB’s own decision under Section 5 always lands in the higher regime (Section 8(3)). Use the rule for a first estimate, not as a conclusion.

A provider has one regime for all its regulated services. If a single service falls into the higher regime, the higher regime applies to the whole organization. The usual trap is to work out the regime for the main system and overlook a marginal service that moves the entire entity up.

A group that knows NIS2 from home will look for essential and important entities. Section 18(4) treats providers in the higher regime as essential entities and providers in the lower regime as important entities, but only for the purposes of Commission Implementing Regulation (EU) 2024/2690. Outside that narrow purpose, the honest phrase is that the higher obligations regime roughly corresponds to an essential entity and the lower obligations regime to an important entity. The regime itself is settled by the decree issued under Section 8(2) and by NÚKIB’s registration decision, not by the mapping.

In the lower obligations regime, NÚKIB divides the measures into mandatory measures, which the provider must always implement (“neopominutelná” in Czech; Sections 3 to 6 and 10 of Decree No. 410/2025 Coll.), and assessable measures, whose extent the provider assesses and which it may, with documented reasons, decide not to implement (“vyhodnotitelná”). Both English terms are a SYSNETSHIELD translation; NÚKIB has no English text of the Decrees. The reasons for a measure left out go into the overview of security measures. That isn’t an escape route: it’s a written commitment that an inspector will one day read and compare with the state of the network.

Notify the regulated service through the NÚKIB Portal within 60 days of the day the service meets the conditions of Section 4(1), as Section 6(1) requires. NÚKIB then decides on registration (Section 6(2)). Within 30 days of delivery of the registration decision you report contact details and supplementary data (Section 11(1)); within one year of receipt you must be implementing security measures (Section 13(4)) and reporting incidents (Section 15(4)).

Three verbs, three different steps. You notify the service; NÚKIB registers it by decision; you report contact details, supplementary data, and later incidents. Supplementary data means the ownership structure of the provider, technical data on the service, and its geographical spread and cross-border provision (Section 11(1)(b)), so the parent company should have the group structure chart ready. You notify changes that may affect the regime within 60 days (Section 9(1)).

Not in formal proceedings. Proceedings with NÚKIB (registration decisions, inspections, offense cases) follow the Czech Administrative Procedure Code, which sets Czech as the language of proceedings; Slovak is accepted, and documents in other languages need a certified Czech translation unless the Agency waives it (Section 16 of Act No. 500/2004 Coll.). NÚKIB’s English website and its unofficial English translation of the Act are informational, not a filing channel.

Notifications, data reporting, and incident reports must be filed through the NÚKIB Portal (Section 45(2) of the Act); a filing made any other way has no effect. The one exception is an incident report when the Portal cannot be used (Section 16(4)). You log in through the Czech eID system (“Identita občana”), and a managing director without a Czech eID authorizes a representative through the company’s data box, the Czech government e-delivery system. Plan for a Czech-speaking contact person or a local partner before the first deadline, not after it.

In the higher obligations regime, yes. Decree No. 409/2025 Coll., Section 24(5), requires penetration testing of technical assets, from the internal and the external communication network, before commissioning, in connection with a significant change, and at least once every two years; Section 24(4) adds an annual vulnerability scan. In the lower regime, Decree No. 410/2025 Coll., Section 12, asks only for regular vulnerability scanning: no interval, no penetration test.

The English wording of the Decrees on this page is our translation. Two details matter for planning. In justified cases the testing may be split into systematic parts completed within five years (Section 24(5)(d)), so “every two years” is the rule, not an absolute. And a significant change means one under the Decree’s change management rules (Section 11(3)). The scan is no substitute either way: the Decree asks for it alongside the penetration test, not instead of it. What a scan finds and what only a test finds are different things.

The Act itself does not order anyone to test. It defines the term in Section 39(1)(e), among the measures NÚKIB may impose during a state of cyber emergency: “identify and validate vulnerabilities by simulating a real attack (hereinafter ‘penetration test’).” The regular testing duty is in the Decree.

The Decree says that you must test, not how. Scope, depth, and the form of the deliverable are yours to choose, and the auditor then asks for evidence, not for good intentions. What a test delivers and what its report contains are the same for every layer, and because the report carries a date, a scope, and reproduction steps, it drops into the risk treatment plan and into the audit record.

Can your group’s existing vendor abroad run the test? The Decree doesn’t say who tests. It asks for a scope that covers the technical assets of the Czech regulated service, a record of the test date and the individuals who performed it (Section 24(5)(e)), and a retest (Section 24(6)). In our reading, a test of the group perimeter that never touches the Czech network and its Active Directory doesn’t document compliance with Section 24 for the Czech entity. A report in English works for the group; if NÚKIB inspects (Section 55 of the Act), the record has to be retrievable, and in any proceedings, documents in another language need a certified Czech translation unless the Agency waives it (Section 16 of the Administrative Procedure Code).

Which layer you test depends on what the Czech entity runs. For networks and Active Directory, that means the internal network and Active Directory test for Section 24 of the Decree. Applications and APIs are tested differently, and the effort follows the number of user roles, not the number of servers. Accounts with a cloud provider have their own scope and their own rules, so permissions and configuration in AWS are tested separately.

Neither Decree prescribes a format. The report has to answer three questions: what exactly was tested, what was found, and what you did about the findings. The higher regime requires two elements: the record of the test date and the individuals who performed it (Section 24(5)(e)) and the retest of findings (Section 24(6)). A report that handles the first two questions passes technically and fails the audit on the third.

• Scope and date: the exact list of addresses, applications, roles, and the test period. Without it nobody can tell what the report covers and what it doesn’t.
• Methodology with name and version (OWASP, PTES, NIST SP 800-115), so the approach can be checked.
• Findings rated Critical / High / Medium / Low with a CVSS score, not just a colored icon.
• Reproduction steps for every finding: request, response, step by step. A developer must be able to repeat it without a phone call.
• Retest with its own date and status for every finding. This answers the third question; without it the report documents only half the work. In the higher regime, Section 24(6) of Decree No. 409/2025 Coll. requires it directly.

The executive summary and the technical section belong in one document, but not in the same chapter. The managing director needs two pages on risk and the cost of fixing it. The developer needs the request, the response, and the exact endpoint. We write both and don’t blend them.

A report ages as fast as the architecture it describes: if it has changed since the test, document a retest or a new test, not last year’s PDF with a nice cover page.

Through the NÚKIB Portal, in up to four steps: an initial report within 24 hours of identifying the incident; if the incident has a significant impact, an incident notification within 72 hours of becoming aware of it, an interim report on request, and a final report within 30 days of the notification. Providers in the higher regime report to NÚKIB, those in the lower regime to the National CERT.

You report only an incident that meets three criteria at once: it occurred within the defined scope, it originated in cyberspace, and an intentional cause cannot be ruled out within the 24-hour time limit (Section 15(1)). Without the third, you would be reporting outages with no link to cyberspace, such as a burned-out power supply in the server room. NÚKIB’s guidance reads the 24 hours as running from the moment the designated person assesses the event as a cybersecurity incident. The National CERT is the national team for the coordination and management of cybersecurity incidents, events, and threats; providers in the lower obligations regime report there (Section 15(2)).

Beyond the two regimes covered above, a group with NIS2 experience at home will notice two more differences. First, who judges significance: in the higher obligations regime you report every incident that meets the three criteria, and NÚKIB tells you within 24 hours of the initial report whether it has a significant impact on national cyberspace (Section 16(2)); only then do the 72-hour notification and the final report follow (Section 16(3)). Second, the final report: 30 days under the Act, one month under NIS2, same anchor, different unit. The Act may go further than the Directive; Article 5 of NIS2 allows Member States a higher level of cybersecurity.

In the lower obligations regime, you judge significance yourself, by the method in Decree No. 410/2025 Coll., Section 14 (our translation): you set a tolerable level of harm in advance and treat an incident as significant when it exceeds that level or when one of the assessment areas (operational impact, users, data sensitivity, cause) comes out as significant.

If the NÚKIB Portal cannot be used, for instance because of the incident itself, Section 16(4) allows reporting by email or data box: [email protected] or data box zzfnkp3 for the higher obligations regime, [email protected] or data box h4axdn8 for the National CERT. A phone call is not an official reporting channel. Providers covered by Commission Implementing Regulation (EU) 2024/2690 of October 17, 2024, from DNS and cloud to online marketplaces and managed security services, report incidents with a significant impact by the method in the Implementing Regulation (Section 18(2)).

The time limits look manageable on paper and fail on one question: who decides at 11:40 p.m. on a Friday that this is an incident. That isn’t tested with a document but with an exercise. A phishing exercise that shows whether anyone reports the incident in time, run with a realistic scenario, measures how long the first report takes to reach the help desk and whether anyone there recognizes it.

The Czech Cybersecurity Act reaches a supplier mostly through the contract, and directly in three cases. The obligations in the Act sit with the regulated service provider, not with its suppliers. Section 13(5) obliges every provider, in both regimes, to select suppliers according to the security measures and to write the resulting requirements into the contract; a missing clause is an offense on the provider’s side (Section 59).

In the higher obligations regime, Decree No. 409/2025 Coll., Section 9, adds supplier management. Expect the following from a Czech customer in that regime: a risk assessment before contracting, a contractual split of who implements and who checks each measure, regular checks of your measures by the customer or a third party, and, if you count as a significant supplier, the contract provisions listed in Annex 5 to the Decree. Such a supplier is told in writing that it has been recorded as one.

Three provisions reach a supplier directly. Section 17(3) of the Act: on NÚKIB’s request, every person provides the information and cooperation needed to handle an incident. Section 24 of the Act: during a serious incident, NÚKIB may order a supplier to hand over information and data about the assets used to provide the regulated service. Sections 25 to 33 on strategically important services: NÚKIB may set conditions for, or prohibit, the use of a supplier of a security-significant delivery.

For a foreign vendor this means that the measures your Czech customer must implement become your contract terms, and the customer has a duty to check them, itself or through a third party (Section 9(2) of the Decree). A test report on your own systems, with scope, date, and retest, is the easiest evidence to hand over.