Skip to content

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.

#ActivityReferencePhaseDescription
B1NIS2 Scope DeterminationArt. 2, 3, Annex I/IIPreparationDo we fall under NIS2? Which regime? (Essential/Important)
B1.1— Service categorisationArt. 3, Annex I/IIPreparationCloud computing, ICT service, DNS, email, or other?
B1.2Size assessmentArts. 2–3; SME recommendationPreparationEmployees, turnover, balance sheet and relevant partner/linked enterprises
B1.3Czech service notification and registrationAct No. 264/2025 Coll.PreparationNotify the service within the actual statutory period; record delivery of the registration decision
B2GAP AnalysisArt. 21AnalysisAssessment of current state vs. NIS2 requirements
B2.1— Current state assessmentArt. 21AnalysisAudit of current security measures
B2.2— Gap identificationArt. 21(2)AnalysisIdentify gaps vs. the 10 baseline measures
B2.3— Remediation roadmapArt. 21AnalysisRemediation plan with priorities
B3Governance & ManagementArt. 20GovernanceManagement accountability for cybersecurity
B3.1— Management accountabilityArt. 20(1); Decree 409/410 § 4GovernanceThe management body approves risk-management measures, oversees implementation and may be held liable; more than board approval of a policy
B3.2— Management trainingArt. 20(2)GovernanceCybersecurity training for management
B3.3Security committeeDecree 409 § 4(3); Decree 410 § 4GovernanceGeneral higher regime: mandatory committee (management member or delegate and cybersecurity manager), meeting at least annually with minutes; lower regime: designated responsible person
B4ISMS SetupArt. 21; Act § 14ImplementationSecurity management under the applicable regime; ISMS mandatory in the general higher regime, ISO/IEC 27001 optional
B4.1— Security policyArt. 21(2)(a)ImplementationInformation security policy
B4.2— Asset InventoryArt. 21(2)(i); Act § 12ImplementationIdentify primary and supporting assets, dependencies and scope; record and regularly update them, not only critical hardware/software
B4.3— Risk AssessmentArt. 21(2)(a); Decree 409 § 8; Regulation 2690 Annex 2.1ImplementationDocumented methodology under the applicable regime; NIS2 does not prescribe a single method. Apply the periods and alternatives below
B4.4— Risk Treatment PlanDecree 409 § 8 and Annex 4; Regulation 2690 Annex 2.1ImplementationPlan, 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
B5Security measures — 10 areasArt. 21(2)(a)–(j)ImplementationTen minimum areas expanded into multiple rows here; organisational and technical measures
B5.1— Risk management policiesArt. 21(2)(a)ImplementationPolicies and procedures for risk management
B5.2— Incident handlingArt. 21(2)(b)ImplementationIncident resolution processes
B5.3— Business continuityArt. 21(2)(c)ImplementationBCP, DRP, crisis management
B5.4— Supply chain securityArt. 21(2)(d)ImplementationSupply chain security
B5.5— Secure acquisition & developmentArt. 21(2)(e)ImplementationSecurity in the acquisition, development and maintenance of network and information systems
B5.6— Vulnerability handlingArt. 21(2)(e)ImplementationVulnerability management, disclosure
B5.7— Security effectivenessArt. 21(2)(f)ImplementationMeasuring security measure effectiveness
B5.8— Cyber hygiene & trainingArt. 21(2)(g)ImplementationBasic cyber hygiene, training
B5.9— CryptographyArt. 21(2)(h)ImplementationPolicies and procedures for cryptography and, where appropriate, encryption
B5.10— HR securityArt. 21(2)(i)ImplementationHR security, access control and asset management
B5.11— MFA & secure authArt. 21(2)(j)ImplementationWhere appropriate, MFA or continuous authentication, secured voice, video, text and emergency communications within the entity
B6Technical Controls DetailArt. 21(2)ImplementationSpecific technical controls
B6.1— Encryption at restArt. 21(2)(h)ImplementationExample implementation to validate by risk and applicable rules: AES-256 for data at rest
B6.2— Encryption in transitArt. 21(2)(h)ImplementationExample 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 11ImplementationIdentity and permissions under the applicable regime, including MFA/continuous authentication and conditions for interim alternatives; see below
B6.4— Patch ManagementArt. 21(2)(e)ImplementationExample implementation to validate by risk and applicable rules: Patch SLA <30 days for critical
B6.5— Monitoring & Logging (SIEM)Art. 21(2)(b)ImplementationExample implementation to validate by risk and applicable rules: monitoring and retention determined by purpose and law
B6.6— Backup & RecoveryArt. 21(2)(c)ImplementationExample implementation to validate by risk and applicable rules: 3-2-1 backup, tested quarterly
B6.7— Firewall & IDS/IPSArt. 21(2)(e)ImplementationExample implementation to validate by risk and applicable rules: Perimeter and internal firewall, IDS/IPS
B6.8— Endpoint protectionArt. 21(2)(e)ImplementationExample implementation to validate by risk and applicable rules: EDR/XDR on all endpoints
B6.9— Network segmentationArt. 21(2)(e)ImplementationExample implementation to validate by risk and applicable rules: Network segmentation, microsegmentation
B7Incident ResponseArt. 21(2)(b), 23ImplementationIncident Response Plan and processes
B7.1— Incident Response PlanArt. 21(2)(b)ImplementationDocumented IRP
B7.2— Incident Response TeamArt. 21(2)(b)ImplementationDefined IRT with roles
B7.3On-call coverageArt. 21(2)(b) — exampleImplementationCapacity appropriate to service and applicable rules; 24/7 on-call is an implementation option
B7.4— Incident classificationArt. 23(3)ImplementationIncident severity classification
B7.5— Evidence preservationArt. 21(2)(b)ImplementationForensics, chain of custody
B8Incident ReportingAct §§ 15–16,18; NIS2 Art. 23ReportingCzech higher regime: NÚKIB; lower: National CERT; see reporting scope and the specific digital-service regime below
B8.1Early warningAct § 16(1); NIS2 Art. 23(4)(a)ReportingCzech 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.2Incident notificationAct § 16(3)(a); Art. 23(4)(b)ReportingIn § 16(3) cases, without undue delay within 72 hours of detection; trust services within 24 hours. Interim report on request under point (b)
B8.3Final reportAct § 16(3)(c); Art. 23(4)(d)–(e)ReportingCzech 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 establishedAct §§ 11,16(4)ReportingContact and supplementary data within 30 days of delivery; relevant changes within 14 days. Report through the portal, using statutory fallback channels if unavailable
B9Business ContinuityArt. 21(2)(c)ImplementationBCM/DRP plans
B9.1— Business Impact AnalysisArt. 21(2)(c); Decree 409 § 15; Regulation 2690 Annex 4.1ImplementationAssess impacts within the defined scope and determine priorities, recovery time and acceptable losses under the applicable regime
B9.2— Business Continuity PlanArt. 21(2)(c)ImplementationBCP documentation
B9.3— Disaster Recovery PlanArt. 21(2)(c)ImplementationDRP with RTO/RPO
B9.4— RTO/RPO definedArt. 21(2)(c)ImplementationExample implementation to validate by risk and applicable rules: RTO <4h, RPO <1h for critical
B9.5— DR testing (annual)Art. 21(2)(c)TestingExample implementation to validate by risk and applicable rules: Annual DR plan testing
B10Supply Chain SecurityArt. 21(2)(d)ImplementationSupplier and third-party security
B10.1— Vendor risk assessmentArt. 21(2)(d),21(3); Act § 13(5)ImplementationConsider each direct supplier and service provider; scale assessment to risk and the specific regime, without limiting legal scope to critical suppliers
B10.2— Security questionnaireArt. 21(2)(d)ImplementationExample implementation to validate by risk and applicable rules: Standardised security questionnaire
B10.3— Vendor certifications (ISO/SOC)Art. 21(2)(d)ImplementationExample 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 controlArt. 21(2)(d)ImplementationVendor access management, JIT access
B10.5— Vendor monitoringArt. 21(2)(d)ImplementationOngoing vendor monitoring
B11Vulnerability ManagementArt. 21(2)(e)TestingVulnerability management
B11.1— Vulnerability scanningArt. 21(2)(e)TestingExample implementation to validate by risk and applicable rules: Monthly vulnerability scanning
B11.2— Penetration testingArt. 21(2)(e)TestingExample implementation to validate by risk and applicable rules: Annual penetration tests
B11.3— Patch SLA definedArt. 21(2)(e)ImplementationExample implementation to validate by risk and applicable rules: Critical <7d, High <30d, Medium <90d
B11.4— Vulnerability disclosureArt. 21(2)(e)GovernanceCoordinated vulnerability disclosure policy
B12Training & AwarenessArt. 21(2)(g)TrainingEmployee cybersecurity training
B12.1— Security awareness programmeArt. 21(2)(g)TrainingRegular awareness training
B12.2— Phishing simulationsArt. 21(2)(g)TrainingExample implementation to validate by risk and applicable rules: Quarterly phishing tests
B12.3— Role-specific trainingArt. 21(2)(g)TrainingSpecialised training for IT, developers
B12.4— Training recordsDecree 409 § 10(5); Decree 410 § 5(3)TrainingTraining and attendee records under the applicable regime
B13Continuous Monitoring (SOC)Decree 409 § 23; Decree 410 § 9; Regulation 2690 Annex 3.2MonitoringDetection, recording and evaluation under the regime; 409 requires continuous evaluation. A SOC is an implementation option, not itself a statutory requirement
B13.1— SOC capabilityArt. 21(2)(b)MonitoringExample implementation to validate by risk and applicable rules: Internal SOC or managed SOC
B13.2— Threat detectionArt. 21(2)(b)MonitoringThreat detection (SIEM, EDR, NDR)
B13.3— Security metricsArt. 21(2)(f)MonitoringSecurity KPIs
B13.4— Threat intelligenceArt. 21(2)(b)MonitoringThreat intelligence feed integration
B14Security AuditsArt. 21(2)(f); Decree 409 § 16; Regulation 2690 Annex 2.3AuditIndependent assessment and statutory intervals under the specific regime; see mandatory higher-regime audits and exception conditions below
B14.1— Internal auditsArt. 21(2)(f)AuditExample implementation to validate by risk and applicable rules: Monthly internal audits
B14.2— External auditsArt. 21(2)(f)AuditExample implementation to validate by risk and applicable rules: Bi-annual external audits
B14.3— Audit findings trackingArt. 21(2)(f)AuditTracking findings and remediation
B15ISO 27001 CertificationRecommendedCertificationFormal certification (strongly recommended)
B15.1— ISO 27001 gap analysisISO 27001CertificationGAP analysis vs. ISO 27001
B15.2— ISO 27001 Stage 1 auditISO 27001CertificationDocumentation audit
B15.3— ISO 27001 Stage 2 auditISO 27001CertificationImplementation audit
B15.4— CertificationISO 27001CertificationObtain 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.

ControlRequirementReference
Encryption at restAES-256Art. 21(2)(h)
Encryption in transitTLS 1.3Art. 21(2)(h)
Access ControlMFA + RBACArt. 21(2)(i,j)
Patch Management<30 daysArt. 21(2)(e)
Monitoring & Loggingmonitoring; purpose-based retentionArt. 21(2)(b)
Incident ResponseIRP written, testedArt. 21(2)(b)
Backup & RecoveryWeekly, tested quarterlyArt. 21(2)(c)
Vendor SecurityDue diligenceArt. 21(2)(d)

Implementation order

  1. Determine scope and the actual reporting/registration status.
  2. Record the delivery date of the registration decision and resulting legal deadlines.
  3. Prioritise risk treatment, incident reporting capability and continuity before the relevant deadline.
  4. 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.