NIS2: questions to assess your obligations
Deadline: Notify the service under § 6(1) within 60 days of meeting the conditions. In the general regime, start complying with the duty to implement and operate measures under § 13(2) and report incidents under § 15(1)–(2) no later than one year from delivery of the registration decision for each regulated service (§ 13(4), § 15(4)). Submit contact and supplementary data within 30 days of delivery (§ 11(1)); report changes to data not held as reference data in the basic registers within 14 days of the change (§ 11(2)). Section 13(2) does not apply to § 18(1) services, so its one-year period cannot automatically be transferred to their measures; assess reporting under § 18(2)–(3) and §§ 15–16. Previously regulated persons have transitional duties under § 71, including the new reporting method from delivery of registration. A move from the lower to the higher regime starts new periods under § 9(2). This is neither a new deadline for the first service notification nor general permission to defer existing duties.
How to read the Czech requirements: Determine the scope under § 12 of the Cybersecurity Act and the applicable regime for each service. The requirements of Decrees 409/2025 (higher obligations) and 410/2025 (lower obligations) below concern the general regime under § 13(2). Services listed in § 18(1) follow the specific measures in Regulation (EU) 2024/2690, rather than automatically the complete Czech decree checklist; other services of the same provider remain subject to their applicable duties. In the lower regime, distinguish proportionality under Decree 410 § 3(1)(a) from the mandatory minimum in point (b) (§ 3(2)–(6), §§ 4–6 and § 10). Document reasons for measures not implemented in the overview under § 3(2). In the higher regime, non-application of some measures must be based on risk management (Decree 409 § 8(4)); it is not an unrestricted choice. Under Regulation 2690, document non-application of conditional requirements as required by Article 2(2). This overview is not a complete inventory of the applicable measures and annexes.
Part B: NIS2 Compliance
This working list combines legal areas and implementation options; B1–B15 are not statutory provisions. For technologies and intervals, apply the conditions and minimum requirements of the relevant regime described below.
| # | Activity | Reference | Phase | Description |
|---|---|---|---|---|
| B1 | NIS2 Scope Determination | Art. 2, 3, Annex I/II | Preparation | Do we fall under NIS2? Which regime? (Essential/Important) |
| B1.1 | — Service categorisation | Art. 3, Annex I/II | Preparation | Cloud computing, ICT service, DNS, email, or other? |
| B1.2 | Size assessment | Arts. 2–3; SME recommendation | Preparation | Employees, turnover, balance sheet and relevant partner/linked enterprises |
| B1.3 | Czech service notification and registration | Act No. 264/2025 Coll. | Preparation | Notify the service within the actual statutory period; record delivery of the registration decision |
| B2 | GAP Analysis | Art. 21 | Analysis | Assessment of current state vs. NIS2 requirements |
| B2.1 | — Current state assessment | Art. 21 | Analysis | Audit of current security measures |
| B2.2 | — Gap identification | Art. 21(2) | Analysis | Identify gaps vs. the 10 baseline measures |
| B2.3 | — Remediation roadmap | Art. 21 | Analysis | Remediation plan with priorities |
| B3 | Governance & Management | Art. 20 | Governance | Management accountability for cybersecurity |
| B3.1 | — Management accountability | Art. 20(1); Decree 409/410 § 4 | Governance | The management body approves risk-management measures, oversees implementation and may be held liable; more than board approval of a policy |
| B3.2 | — Management training | Art. 20(2) | Governance | Cybersecurity training for management |
| B3.3 | Security committee | Decree 409 § 4(3); Decree 410 § 4 | Governance | General higher regime: mandatory committee (management member or delegate and cybersecurity manager), meeting at least annually with minutes; lower regime: designated responsible person |
| B4 | ISMS Setup | Art. 21; Act § 14 | Implementation | Security management under the applicable regime; ISMS mandatory in the general higher regime, ISO/IEC 27001 optional |
| B4.1 | — Security policy | Art. 21(2)(a) | Implementation | Information security policy |
| B4.2 | — Asset Inventory | Art. 21(2)(i); Act § 12 | Implementation | Identify primary and supporting assets, dependencies and scope; record and regularly update them, not only critical hardware/software |
| B4.3 | — Risk Assessment | Art. 21(2)(a); Decree 409 § 8; Regulation 2690 Annex 2.1 | Implementation | Documented methodology under the applicable regime; NIS2 does not prescribe a single method. Apply the periods and alternatives below |
| B4.4 | — Risk Treatment Plan | Decree 409 § 8 and Annex 4; Regulation 2690 Annex 2.1 | Implementation | Plan, owners, dates and acceptability under the regime; under 409 apply measures above the acceptability threshold, under 2690 management or authorised persons accept assessment results and residual risks with reporting to management |
| B5 | Security measures — 10 areas | Art. 21(2)(a)–(j) | Implementation | Ten minimum areas expanded into multiple rows here; organisational and technical measures |
| B5.1 | — Risk management policies | Art. 21(2)(a) | Implementation | Policies and procedures for risk management |
| B5.2 | — Incident handling | Art. 21(2)(b) | Implementation | Incident resolution processes |
| B5.3 | — Business continuity | Art. 21(2)(c) | Implementation | BCP, DRP, crisis management |
| B5.4 | — Supply chain security | Art. 21(2)(d) | Implementation | Supply chain security |
| B5.5 | — Secure acquisition & development | Art. 21(2)(e) | Implementation | Security in the acquisition, development and maintenance of network and information systems |
| B5.6 | — Vulnerability handling | Art. 21(2)(e) | Implementation | Vulnerability management, disclosure |
| B5.7 | — Security effectiveness | Art. 21(2)(f) | Implementation | Measuring security measure effectiveness |
| B5.8 | — Cyber hygiene & training | Art. 21(2)(g) | Implementation | Basic cyber hygiene, training |
| B5.9 | — Cryptography | Art. 21(2)(h) | Implementation | Policies and procedures for cryptography and, where appropriate, encryption |
| B5.10 | — HR security | Art. 21(2)(i) | Implementation | HR security, access control and asset management |
| B5.11 | — MFA & secure auth | Art. 21(2)(j) | Implementation | Where appropriate, MFA or continuous authentication, secured voice, video, text and emergency communications within the entity |
| B6 | Technical Controls Detail | Art. 21(2) | Implementation | Specific technical controls |
| B6.1 | — Encryption at rest | Art. 21(2)(h) | Implementation | Example implementation to validate by risk and applicable rules: AES-256 for data at rest |
| B6.2 | — Encryption in transit | Art. 21(2)(h) | Implementation | Example implementation to validate by risk and applicable rules: TLS 1.3 for data in transit |
| B6.3 | — Access Control (MFA + RBAC) | Decree 409 § 19; Decree 410 § 8; Regulation 2690 Annex 11 | Implementation | Identity and permissions under the applicable regime, including MFA/continuous authentication and conditions for interim alternatives; see below |
| B6.4 | — Patch Management | Art. 21(2)(e) | Implementation | Example implementation to validate by risk and applicable rules: Patch SLA <30 days for critical |
| B6.5 | — Monitoring & Logging (SIEM) | Art. 21(2)(b) | Implementation | Example implementation to validate by risk and applicable rules: monitoring and retention determined by purpose and law |
| B6.6 | — Backup & Recovery | Art. 21(2)(c) | Implementation | Example implementation to validate by risk and applicable rules: 3-2-1 backup, tested quarterly |
| B6.7 | — Firewall & IDS/IPS | Art. 21(2)(e) | Implementation | Example implementation to validate by risk and applicable rules: Perimeter and internal firewall, IDS/IPS |
| B6.8 | — Endpoint protection | Art. 21(2)(e) | Implementation | Example implementation to validate by risk and applicable rules: EDR/XDR on all endpoints |
| B6.9 | — Network segmentation | Art. 21(2)(e) | Implementation | Example implementation to validate by risk and applicable rules: Network segmentation, microsegmentation |
| B7 | Incident Response | Art. 21(2)(b), 23 | Implementation | Incident Response Plan and processes |
| B7.1 | — Incident Response Plan | Art. 21(2)(b) | Implementation | Documented IRP |
| B7.2 | — Incident Response Team | Art. 21(2)(b) | Implementation | Defined IRT with roles |
| B7.3 | On-call coverage | Art. 21(2)(b) — example | Implementation | Capacity appropriate to service and applicable rules; 24/7 on-call is an implementation option |
| B7.4 | — Incident classification | Art. 23(3) | Implementation | Incident severity classification |
| B7.5 | — Evidence preservation | Art. 21(2)(b) | Implementation | Forensics, chain of custody |
| B8 | Incident Reporting | Act §§ 15–16,18; NIS2 Art. 23 | Reporting | Czech higher regime: NÚKIB; lower: National CERT; see reporting scope and the specific digital-service regime below |
| B8.1 | Early warning | Act § 16(1); NIS2 Art. 23(4)(a) | Reporting | Czech initial report for a reportable incident without undue delay, within 24 hours of detection; the general higher regime also covers incidents without significant impact |
| B8.2 | Incident notification | Act § 16(3)(a); Art. 23(4)(b) | Reporting | In § 16(3) cases, without undue delay within 72 hours of detection; trust services within 24 hours. Interim report on request under point (b) |
| B8.3 | Final report | Act § 16(3)(c); Art. 23(4)(d)–(e) | Reporting | Czech Republic: within 30 days of notification; if still ongoing after the deadline, progress report without undue delay and final report within 30 days of resolution. NIS2 uses one month |
| B8.4 | — Authority contact established | Act §§ 11,16(4) | Reporting | Contact and supplementary data within 30 days of delivery; relevant changes within 14 days. Report through the portal, using statutory fallback channels if unavailable |
| B9 | Business Continuity | Art. 21(2)(c) | Implementation | BCM/DRP plans |
| B9.1 | — Business Impact Analysis | Art. 21(2)(c); Decree 409 § 15; Regulation 2690 Annex 4.1 | Implementation | Assess impacts within the defined scope and determine priorities, recovery time and acceptable losses under the applicable regime |
| B9.2 | — Business Continuity Plan | Art. 21(2)(c) | Implementation | BCP documentation |
| B9.3 | — Disaster Recovery Plan | Art. 21(2)(c) | Implementation | DRP with RTO/RPO |
| B9.4 | — RTO/RPO defined | Art. 21(2)(c) | Implementation | Example implementation to validate by risk and applicable rules: RTO <4h, RPO <1h for critical |
| B9.5 | — DR testing (annual) | Art. 21(2)(c) | Testing | Example implementation to validate by risk and applicable rules: Annual DR plan testing |
| B10 | Supply Chain Security | Art. 21(2)(d) | Implementation | Supplier and third-party security |
| B10.1 | — Vendor risk assessment | Art. 21(2)(d),21(3); Act § 13(5) | Implementation | Consider each direct supplier and service provider; scale assessment to risk and the specific regime, without limiting legal scope to critical suppliers |
| B10.2 | — Security questionnaire | Art. 21(2)(d) | Implementation | Example implementation to validate by risk and applicable rules: Standardised security questionnaire |
| B10.3 | — Vendor certifications (ISO/SOC) | Art. 21(2)(d) | Implementation | Example implementation to validate by risk and applicable rules: evaluate an ISO 27001 certificate / SOC 2 report where relevant; not a universal supplier obligation |
| B10.4 | — Vendor access control | Art. 21(2)(d) | Implementation | Vendor access management, JIT access |
| B10.5 | — Vendor monitoring | Art. 21(2)(d) | Implementation | Ongoing vendor monitoring |
| B11 | Vulnerability Management | Art. 21(2)(e) | Testing | Vulnerability management |
| B11.1 | — Vulnerability scanning | Art. 21(2)(e) | Testing | Example implementation to validate by risk and applicable rules: Monthly vulnerability scanning |
| B11.2 | — Penetration testing | Art. 21(2)(e) | Testing | Example implementation to validate by risk and applicable rules: Annual penetration tests |
| B11.3 | — Patch SLA defined | Art. 21(2)(e) | Implementation | Example implementation to validate by risk and applicable rules: Critical <7d, High <30d, Medium <90d |
| B11.4 | — Vulnerability disclosure | Art. 21(2)(e) | Governance | Coordinated vulnerability disclosure policy |
| B12 | Training & Awareness | Art. 21(2)(g) | Training | Employee cybersecurity training |
| B12.1 | — Security awareness programme | Art. 21(2)(g) | Training | Regular awareness training |
| B12.2 | — Phishing simulations | Art. 21(2)(g) | Training | Example implementation to validate by risk and applicable rules: Quarterly phishing tests |
| B12.3 | — Role-specific training | Art. 21(2)(g) | Training | Specialised training for IT, developers |
| B12.4 | — Training records | Decree 409 § 10(5); Decree 410 § 5(3) | Training | Training and attendee records under the applicable regime |
| B13 | Continuous Monitoring (SOC) | Decree 409 § 23; Decree 410 § 9; Regulation 2690 Annex 3.2 | Monitoring | Detection, recording and evaluation under the regime; 409 requires continuous evaluation. A SOC is an implementation option, not itself a statutory requirement |
| B13.1 | — SOC capability | Art. 21(2)(b) | Monitoring | Example implementation to validate by risk and applicable rules: Internal SOC or managed SOC |
| B13.2 | — Threat detection | Art. 21(2)(b) | Monitoring | Threat detection (SIEM, EDR, NDR) |
| B13.3 | — Security metrics | Art. 21(2)(f) | Monitoring | Security KPIs |
| B13.4 | — Threat intelligence | Art. 21(2)(b) | Monitoring | Threat intelligence feed integration |
| B14 | Security Audits | Art. 21(2)(f); Decree 409 § 16; Regulation 2690 Annex 2.3 | Audit | Independent assessment and statutory intervals under the specific regime; see mandatory higher-regime audits and exception conditions below |
| B14.1 | — Internal audits | Art. 21(2)(f) | Audit | Example implementation to validate by risk and applicable rules: Monthly internal audits |
| B14.2 | — External audits | Art. 21(2)(f) | Audit | Example implementation to validate by risk and applicable rules: Bi-annual external audits |
| B14.3 | — Audit findings tracking | Art. 21(2)(f) | Audit | Tracking findings and remediation |
| B15 | ISO 27001 Certification | Recommended | Certification | Formal certification (strongly recommended) |
| B15.1 | — ISO 27001 gap analysis | ISO 27001 | Certification | GAP analysis vs. ISO 27001 |
| B15.2 | — ISO 27001 Stage 1 audit | ISO 27001 | Certification | Documentation audit |
| B15.3 | — ISO 27001 Stage 2 audit | ISO 27001 | Certification | Implementation audit |
| B15.4 | — Certification | ISO 27001 | Certification | Obtain certificate |
Specific rules by regime
- Decree 409: an ISMS and at least annual effectiveness assessment (§ 3); a mandatory committee meeting at least annually with minutes, and specified security roles (§§ 4–5). Assess risks at least annually and on significant changes (§ 8(1)), with the equivalent or better process option under § 8(3) and Annex 4. Audit under a plan, on significant changes within their scope and at least every two years; justified cases may use systematic parts covering the whole scope within five years (§ 16(4)–(5)). The auditor meets § 5(4) and assesses independently; an external firm is not necessarily required.
- Identity and access: Decree 409 § 19 and Decree 410 § 8 specify MFA using two different factor types or currently robust continuous authentication based on zero trust for administrators, users and technical assets. They provide interim alternatives using keys/certificates and then prescribed passwords; Decree 409 also requires records of non-compliant mechanisms. Apply the proportionality rules above. Access must be removed or changed without delay on termination or change of the relationship (Decree 409 § 13(2), Decree 410 § 7(1)).
- Monitoring and testing under 409: retain the events covered by § 22 for at least 18 months; § 23 requires continuous evaluation. Scan vulnerabilities at least annually; penetration testing follows asset and risk assessments before operation, on relevant significant changes and at least every two years, with a justified option for systematic parts within five years and retesting of findings (§ 24). Regularly test continuity plans and backups (§§ 15 and 26).
- Decree 410: update the measures overview and assess effectiveness at least annually; retain overviews and updates for four years (§ 3(2)). Set event retention according to security needs (§ 9(3)). Section 12 requires approved security updates without delay and regular vulnerability scanning; internal SLAs must not defer the applicable duty.
- Regulation 2690: review the security policy, risk-assessment results and treatment plan at least annually and on specified incidents or changes (Annex 1.1.2, 2.1.4). Independent reviews have planned and event-based triggers (2.3); testing frequency follows risk (6.5), and critical vulnerabilities are addressed without undue delay (6.10.2). Authentication rules are in 11.3 and 11.6–11.7; log retention is in 3.2.5. Do not substitute Decree 409 intervals for these rules.
Czech reporting (§§ 15–16): In the general higher-obligation regime, report to NÚKIB incidents arising within the defined scope, originating in cyberspace and for which intentional causation cannot be excluded within the initial 24-hour period, even without a significant impact. The lower regime adds a significant impact on the regulated service to those same conditions; the recipient is the National CERT (§ 15(1)–(3), Decree 410 § 14). Submit the initial report without undue delay and within 24 hours of detection. Further stages under § 16(3) concern a significant impact on the service under § 15(2) or on the state’s cyberspace under § 16(2): notification without undue delay within 72 hours of detection (24 hours for trust services), an interim report on request and a final report within 30 days of notification. If the incident continues beyond that period, submit a progress report without undue delay and a final report within 30 days of resolution. Use the NÚKIB portal; if unavailable, use the designated email or data box of NÚKIB or the National CERT according to the regime (§ 16(4)).
Digital services: Section 18(2) replaces the definition of reportable incidents for the listed services other than trust services; significance is determined by Regulation 2024/2690 (Articles 3–4 and the relevant sector article). The general procedure in §§ 15–16 remains unless EU rules prescribe a specific procedure. Also assess a main establishment or representative in another EU/EEA state (§ 18(3)). The trust-service exception here is not an exemption from incident reporting; Article 1 of Regulation 2690 includes trust services. Keep records of other incidents; § 15(5) allows voluntary reporting. In addition to reporting to an authority, assess the duty to inform users about incidents and significant threats under § 19.
Technical Controls — implementation examples
The following technologies and intervals are examples; establish the actual requirement from the applicable national/EU implementing rule and your risk assessment.
| Control | Requirement | Reference |
|---|---|---|
| Encryption at rest | AES-256 | Art. 21(2)(h) |
| Encryption in transit | TLS 1.3 | Art. 21(2)(h) |
| Access Control | MFA + RBAC | Art. 21(2)(i,j) |
| Patch Management | <30 days | Art. 21(2)(e) |
| Monitoring & Logging | monitoring; purpose-based retention | Art. 21(2)(b) |
| Incident Response | IRP written, tested | Art. 21(2)(b) |
| Backup & Recovery | Weekly, tested quarterly | Art. 21(2)(c) |
| Vendor Security | Due diligence | Art. 21(2)(d) |
Implementation order
- Determine scope and the actual reporting/registration status.
- Record the delivery date of the registration decision and resulting legal deadlines.
- Prioritise risk treatment, incident reporting capability and continuity before the relevant deadline.
- Verify evidence and remediate gaps. ISO 27001 certification is an optional separate project.
The month ranges below are a project-planning example, not statutory deadlines.
Implementation Phases
Resources
Content reviewed: 6 September 2026. Primary sources: NIS2 — Arts. 20–23, NÚKIB — law, NÚKIB — reporting/registration, Implementing Regulation (EU) 2024/2690.
Czech legal basis: 264/2025, 408/2025, 409/2025, 410/2025, 2024/2690.