What this page is and what it is not
The page follows the
real structure of Decree No. 409/2025 Coll. (3 parts, 29 sections, 6 annexes) for the higher-obligations regime. For every § we give the official heading, our short paraphrase of what it regulates, and a separate CypherOn note on the practical impact.
This is neither the official wording nor the full text of the decree. The decree implements Act No. 264/2025 Coll., which is the Czech transposition of the NIS2 Directive —
Directive (EU) 2022/2555 — so if you know NIS2, you will recognise the structure of the obligations. Neither the act nor its decrees have an official English version:
only the Czech wording in the Collection of Laws is binding and the English text on this page is an orientation translation. For the definitive wording and current status always check the Czech text of the decree in the
e-Sbírka or on
Zákony pro lidi, and the Czech text of the act itself in the
e-Sbírka. The lower obligations are covered by a separate
Decree 410/2025 Coll.
Žádný paragraf neodpovídá hledanému výrazu.
Part One
Introductory provisions
The decree sets out the content of the security measures a provider of a regulated service has to apply under the higher-obligations regime, and how they are to be introduced. It transposes Directive (EU) 2022/2555 (NIS 2).
CypherOn note
If you fall under the higher regime (NÚKIB, the national cybersecurity agency, puts you there in the registration decision under § 6 of the act), this decree is your primary implementation document. Deadline for putting the measures in place: 1 year from registration (§ 13 of the act) plus the transitional period under § 28 of this decree.
Defines the working terms: user, administrator, primary and supporting asset, risk assessment, information security management system (ISMS) and others.
CypherOn note
The definitions build on § 2 of the act but pin down the technical terms. The key split between a primary asset (data, information, processes) and a supporting asset (hardware, software, networks, people) determines how you structure the asset inventory (§ 7) and the risk assessment (§ 8).
Part Two · Title I
Organisational measures
§ 3
Information security management system
¶
Duty to establish and run an information security management system (ISMS) as the framework for setting objectives, managing risk and applying proportionate measures across cybersecurity management.
CypherOn note
The ISMS is the backbone of the higher regime. In practice, define its scope in a single document — what is in scope and what is not. Map it onto ISO 27001 Annex A controls; the structure is useful even if you never go for certification. An ISMS runs on PDCA (Plan-Do-Check-Act): an annual plan, continuous implementation and monitoring, an annual management review (§ 4) — without the management review the ISMS falls apart at the audit.
§ 4
Requirements on top management
¶
Responsibility of the statutory body / top management for approving documentation, allocating resources, overseeing the ISMS and taking strategic decisions on risk. Top management also sets up the cybersecurity committee (para. 3), appoints people to the security roles (para. 4) and makes sure the manager and the architect have deputies (para. 5).
CypherOn note
This is the anchor for personal liability of the statutory body: the duty to introduce and apply security measures comes from § 13 of the act, offences committed by the provider are listed in § 59, and under § 58 the Authority can temporarily bar a member of the statutory body from holding office. In practice: the statutory body has to approve the security strategy demonstrably, receive periodic reports (quarterly) and keep a record of key decisions in the board minutes. Watch your D&O insurance — standard policies do not cover breaches of regulatory duties.
Definition of the roles and their responsibilities: cybersecurity manager, cybersecurity architect, cybersecurity auditor, asset owner. Including requirements on independence and qualification.
CypherOn note
The decree names specific roles: cybersecurity manager, cybersecurity architect, cybersecurity auditor, asset owner. The key principle is segregation of roles. The cybersecurity manager must not at the same time be the CIO or the head of IT approving their own measures — an auditor or NÚKIB will challenge that combination. The cybersecurity auditor must not audit an area they run themselves (this ties into § 16). An external manager (CISO-as-a-Service) is a legitimate option, but the contract has to fix capacity and an SLA for reactive situations, plus a written appointment from management. Note: the “cybersecurity committee” is not optional good practice — it is mandatory under § 4 para. 3, it has to include at least one member of top management (or a person they authorise) and the cybersecurity manager, it meets at least once a year and minutes are kept. The manager, the architect and the auditor all have to be trained for the role and show at least 3 years of relevant experience.
§ 6
Managing the security policy and security documentation
¶
Drafting, approving, updating, distributing and keeping records of security policies, directives and supporting ISMS documentation.
CypherOn note
Realistically 8–12 documents: an overarching information security policy, access control, change management, incident handling, supplier management, data classification, cryptography, mobile devices, vulnerability management. We recommend the structure policy (what and why, for management) + standard (how exactly, technical) + procedure (step by step). Versioning + annual review + a structured record of staff acknowledgement: who agreed to which version and when, demonstrably — not a loose e-mail. In practice: an HR system with an acknowledgement workflow, or a dedicated compliance tool (Vanta, Drata).
Identification, records, classification and assignment of owners for primary and supporting assets. Rules for handling, transfer and disposal. References to Annex 1 (asset valuation) and Annex 2 (disposal of information and data).
CypherOn note
For a mid-sized company expect 50–200 rows in the main register. We recommend automating the hardware and software inventory with a discovery tool (Microsoft Intune, Lansweeper, Snipe-IT) and maintaining the business-level assets by hand (processes, key data sets, critical suppliers). The key attribute is the asset owner — without one, the asset ends up hanging on the cybersecurity manager. Classify along confidentiality / integrity / availability (CIA) as set out in Annex 1.
Process for identifying vulnerabilities and threats, assessing risk, a risk treatment plan and its regular review. References to Annex 3 (vulnerabilities and threats) and Annex 4 (risk assessment).
CypherOn note
Practical form: a spreadsheet, a SharePoint list or a dedicated GRC tool. For each risk: ID, threat description, impact, likelihood, current score, treatment, residual score, owner, deadline, status. Authority to accept residual risk has to be defined formally: low risk accepted by the cybersecurity manager, medium by company management, high by the statutory body — always with a written record. Treatment strategies: mitigate (put a control in place), transfer (insurance, contractually onto a supplier), avoid (stop the activity), accept (after formal approval at the matching level — for higher risks by the statutory body).
§ 9
Supplier management
¶
Assessing how significant a supplier is, security requirements in contracts, checking that they are met, and managing supply chain risk. Reference to Annex 5.
CypherOn note
Supplier tiers: critical (their outage means your service is down) → annual security review + a contractual right to audit; significant → review every two years + DPA / DPIA; standard → contractual DPA, no active checks. Annex 5 gives a model set of contract clauses. A more current approach goes beyond a one-off questionnaire — continuous monitoring (SecurityScorecard, BitSight) shows a supplier deteriorating between reviews. For the software supply chain expect an SBOM (CycloneDX / SPDX) and signed artefacts for critical components (SLSA, Sigstore).
§ 10
Human resources security
¶
Security duties at recruitment, onboarding, role change and termination. A plan for building security awareness. Reference to Annex 6.
CypherOn note
Realistically: induction training as part of onboarding, annual security awareness training for all staff (KnowBe4, Cofense, the NÚKIB awareness portal), specialised training for developers (secure coding) and admin roles (privileged access). Phishing simulations 2–4 times a year with escalation. Differentiate off-boarding by scenario: privileged account + involuntary departure = revoke within the hour, ideally before the person is told; standard + voluntary = within 24 h. A monthly reconciliation of active accounts against HR data finds the “zombie” accounts.
A formal process for assessing the security impact of changes to assets and processes, and for approving, testing and documenting them.
CypherOn note
Even a lightweight RFC process in Jira / Linear / GitLab beats ad-hoc changes. For most companies: PR review plus a ticket with checkboxes for “security impact / rollback plan / communication”. The auditor will ask: show me the last 5 changes to production and their approvals. For the higher regime we recommend a Change Advisory Board (CAB) or an equivalent for significant changes.
§ 12
Acquisition, development and maintenance
¶
Security requirements for acquiring, developing and maintaining technical assets. Including a secure SDLC, separation of development / test / production, and version control.
CypherOn note
A practical CI/CD toolset for in-house development: SAST (Snyk Code, SonarQube, GitHub CodeQL), SCA (Snyk Open Source, Dependabot), secret scanning (gitleaks, GitHub native), DAST (OWASP ZAP, Burp Suite Enterprise) against staging, container scanning (Trivy, Snyk Container). Pre-commit hooks to move security to the start of development (the “shift-left” principle — find the vulnerability while the code is being written, not in production). Key rules: no admin access from the dev VPN into production, masked or anonymised data for test environments (not copies of production), infrastructure-as-code with policy-as-code (OPA, Sentinel) for automatic compliance checks.
Rules for granting, reviewing and revoking user and administrator access to assets. Need-to-know and segregation of roles.
CypherOn note
Recommended: Microsoft Entra ID or Okta as the identity provider, SSO to all key applications (over SAML / OIDC), automated provisioning over SCIM. Recertify privileged accounts quarterly, the rest annually. Conditional access rules: the device has to be compliant (enrolled in MDM and recently checked in), block legacy authentication protocols (POP3 / IMAP / SMTP basic auth), geo-block countries you do not operate in, risk-based evaluation (high risk → MFA challenge or block). Zero trust is not a one-year project, it is an architecture — roll it out iteratively. For privileged accounts use PAM (CyberArk, BeyondTrust, Microsoft PIM) with just-in-time elevation.
§ 14
Handling cybersecurity events and incidents
¶
Process for detecting, classifying, reporting (including to NÚKIB), responding to, resolving, escalating and learning from incidents.
CypherOn note
Key playbooks: ransomware, BEC / fraud, data breach, DDoS, insider threat, supply chain compromise. For each one: detection signals, escalation contacts, first steps (4–6 bullets at most), a decision matrix (when to involve legal / communications / NÚKIB / clients). The incident response plan is a short runbook, not a long document. Reporting deadlines (24 h / 72 h / 30 days) come from § 16 of the act. Practical tip: prepare a pre-filled report template with your company registration number, contacts and sector — in a crisis you will not have time to look them up.
§ 15
Business continuity management
¶
Business impact analysis (BIA), continuity and recovery plans for the regulated service, and their testing and updating.
CypherOn note
For every critical process: RTO (Recovery Time Objective — how fast it has to be running again), RPO (Recovery Point Objective — how much data you can afford to lose), scenarios (data centre outage, ransomware, loss of a key supplier, pandemic). A full end-to-end DR test at least once a year, twice a year for key systems. A monthly restore test on a sample of data. Backups on the 3-2-1 rule plus an immutable copy (Veeam Hardened Repository, AWS S3 Object Lock in compliance mode) — ransomware encrypts online backups together with production, and modern ransomware actively targets backup infrastructure (stolen Veeam credentials were a concrete attack vector in 2024).
§ 16
Cybersecurity audit
¶
Regular internal ISMS audits. Requirements on auditor independence, planning, outputs and corrective actions.
CypherOn note
Key principle: an auditor must not audit an area they run themselves. The cybersecurity manager therefore cannot audit the ISMS they manage — either provide a second qualified internal auditor (typically from quality or compliance) or buy the audit externally. An annual plan covering all ISMS domains over a 2-year cycle. Findings: major (risk to the regulated service), minor (a gap in a process), observation (improvement). Every finding has an owner, a deadline and a status. For an external audit we recommend preparing a year ahead: gap analysis, remediation plan, a pre-audit dry run 3 months before the official audit.
Part Two · Title II
Technical measures
Protection of the physical perimeter, entry points, areas holding assets and supporting infrastructure (power, cooling) against unauthorised access and emergencies.
CypherOn note
In a cloud-first environment physical security often comes down to protecting offices and laptops. What matters: MDM with enforced policies (disk encryption, firewall, anti-malware, screen lock), conditional access tied to device compliance, automated inventory and remote wipe. Laptops encrypted from first boot (BitLocker / FileVault / LUKS). Access to the server room, if you have one, only for authorised people, and visitor records in sensitive areas. For data centres, ask the provider to evidence their physical controls — entry regime, visitor records, redundant power and cooling. A description of the controls, an audit report (typically a SOC 2 Type II report) or a certificate (ISO/IEC 27001) all work as evidence; certification is one of the options, not a condition.
§ 18
Communication network security
¶
Segmentation, control of data flows, protection of the network perimeter, securing remote access and wireless transmission.
CypherOn note
Key zones: internet ↔ DMZ ↔ internal applications ↔ databases, a separate management VLAN reachable only from bastion hosts, guest WiFi isolated. In the cloud, micro-segmentation through security groups / network policies. Review firewall rules annually — remove the forgotten “temporary allow ANY” rules that have been sitting there for 5 years. For the higher regime in a multi-cloud environment, consider a CNAPP (Cloud-Native Application Protection Platform — Wiz, Prisma Cloud, Defender for Cloud) as a unifying layer over CSPM + CWPP + CIEM.
§ 19
Identity management and authentication
¶
Rules for managing user and administrator identities. Authentication requirements including multi-factor authentication (MFA) and password management.
CypherOn note
MFA on admin accounts, VPN, RDP, the cloud console and e-mail. For privileged roles use phishing-resistant MFA (FIDO2 / WebAuthn / hardware key) as the primary factor — SMS and TOTP are still better than nothing, but they do not hold up against advanced phishing or AiTM. For the break-glass admin: hardware token + offline PIN, stored in a safe. SMS MFA only as a fallback — SIM swapping is a real risk. In M365/Entra environments add an ITDR layer (Identity Threat Detection & Response — Defender for Identity, Falcon Identity Protection, Semperis): the classic IAM stack assumes the identity provider is a trusted root, while modern attacks go straight at it (token theft, OAuth consent phishing, AiTM after MFA).
§ 20
Managing access rights and permissions
¶
Granting, documenting, periodically reviewing and revoking permissions. Separation of the operational and the privileged account.
CypherOn note
In practice: RBAC through roles (sales, marketing, dev, admin) instead of individual grants. Separate admin accounts (user@ for everyday work, user-admin@ for IT operations). Recertification once a year — a review of active accounts and permissions. Look for the “accumulators” (people who have picked up permissions across roles over the years) — a classic weak point. For privileged roles use just-in-time elevation instead of standing access, session recording for critical operations, and a vault for service accounts (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault).
§ 21
Detection of cybersecurity events
¶
Deploying monitoring tools, IDS/IPS and anti-malware, and generally the ability to detect anomalies and incidents in time.
CypherOn note
EDR / XDR on every endpoint and server. Pick by environment: Microsoft Defender for Endpoint (price and integration in the M365 stack), CrowdStrike Falcon (top-tier detection, but pricier), SentinelOne, ESET (support in Czech). Centralised telemetry, alerting wired into a SOC or MDR. Map detection rules onto the MITRE ATT&CK framework — that lets you measure detection coverage and find the blind spots. An essential entity should have detection capability with 24/7 coverage — an in-house SOC, an MSSP or a hybrid model.
Duties to generate, protect against modification and retain security and operational records (logs) for a set period.
CypherOn note
Centralised collection from all relevant sources (AD/Entra, EDR, firewall, e-mail gateway, cloud audit logs, application logs). Tiered retention: hot (immediately searchable) 90 days or more, warm 12 months, archive 2–3 years depending on sector and regulation. Log integrity is critical — attackers try to wipe logs: use WORM / append-only storage (S3 Object Lock, Azure Immutable Blob, Splunk SmartStore append-only) and hash-chain verification.
§ 23
Evaluation of cybersecurity events
¶
Correlation and analysis of records, evaluation procedures, and feeding the results into incident handling (§ 14).
CypherOn note
Choosing a SIEM: Microsoft Sentinel (pay per GB, good integration), Splunk (most capable, expensive), Elastic Security (open-core), Wazuh (open source). Detection rules plus SOAR playbooks. Cover at least these use cases: impossible travel, privilege escalation, brute force, data exfiltration, known malicious IP addresses. Manage the rules as code — Sigma rules in Git, a CI/CD pipeline that deploys them into the SIEM (detection-as-code).
§ 24
Application security
¶
Using supported technical assets and applying approved security updates, keeping records of assets that are out of support, protecting applications, transactions and session identifiers. Also vulnerability scanning from the internal and the external network at least once a year and penetration testing at least once every 2 years, including retesting of the findings.
CypherOn note
🚨 The intervals here are not recommendations, they are the text of the decree: vulnerability scanning at least once a year from both the internal and the external communication network (para. 4), penetration testing at least once every 2 years, plus before an asset goes live and after a significant change (para. 5). If a penetration test cannot cover the whole scope at once, it can be split into systematic blocks, but the full scope has to be covered within 5 years at the latest. For penetration tests you record the date and the individuals who carried them out. Results of both the scans and the tests have to feed into risk management under § 8. For development see § 12 (secure SDLC). In production: a WAF in front of exposed web applications, OWASP ZAP / Burp Suite for continuous scanning beyond the annual minimum. Container runtime protection — SAST/SCA/SBOM covers build time, but a production container needs its own detection layer: Falco or Tetragon (eBPF-based detection of unusual syscalls and processes), Wiz Runtime Sensor, Sysdig Secure, Defender for Cloud runtime.
§ 25
Cryptographic algorithms
¶
Using trustworthy algorithms, key management, protecting data in transit and at rest. Alignment with the NÚKIB cryptography guidance.
CypherOn note
Current baseline (2025–2026): symmetric AES-256-GCM; asymmetric RSA 3072 and above, or ECC P-256 and above; hash SHA-256 and above (NEVER MD5 or SHA-1); TLS 1.2 minimum, 1.3 preferred. Post-quantum cryptography has stopped being theory — in August 2024 NIST finalised FIPS 203 (ML-KEM), FIPS 204 (ML-DSA) and FIPS 205 (SLH-DSA). For an essential entity we recommend, by 2026: an inventory of cryptographic assets, crypto-agility in the design (the option to swap the algorithm without rewriting the application), a hybrid KEM (classical + ML-KEM) for data that has to stay confidential for a long time — because of “Harvest Now, Decrypt Later” attacks. Keys in a cloud KMS (AWS KMS, Azure Key Vault, GCP KMS) or an HSM. Rotation: TLS certificates keep getting shorter — in April 2025 the CA/Browser Forum approved a stepped reduction of the maximum lifetime of public TLS certificates (398 → 200 → 100 → 47 days) by 15 March 2029, so full automation over ACME is a necessity today; SSH and API keys 90 days or less for automation, a year or less for human users.
§ 26
Ensuring availability of the regulated service
¶
Measures against overload, redundancy, DDoS protection and, in general, keeping the service within its availability targets.
CypherOn note
Practical minimum: redundancy for critical components (HA for the database, a load balancer plus 2 or more application servers), a CDN with DDoS protection (Cloudflare, Akamai, AWS Shield), DNS with anycast and failover, SLA monitoring with alerts. For the higher regime expect formal availability monitoring (an SLA dashboard, MTTR/MTBF reporting to the statutory body). For strategically significant services see § 33 of the act — availability from the territory of the Czech Republic.
§ 27
Securing industrial, control and similar specific technical assets
¶
Specifics of OT/ICS environments — segmentation from IT, monitoring, restricted remote access, keeping the process itself safe.
CypherOn note
IT-oriented guidance cannot be applied mechanically to an OT environment (industrial control systems — SCADA, DCS, PLC), which is why § 27 sets separate requirements for it. IT tooling (EDR, MDM) does not run on PLCs and HMIs. For OT/ICS follow IEC 62443 (ČSN EN 62443 in the Czech Republic) and NIST SP 800-82. Specialised OT monitoring vendors: Claroty, Nozomi Networks, Dragos, Tenable.OT. Key principles: the Purdue model for segmentation, one-way gateways (data diodes) between the OT and the IT zone, passive monitoring without active scanning (asset discovery against a PLC can take it down), changes only in planned maintenance windows (never patch PLC firmware ad-hoc — always with a rollback plan and verification in a test environment). If you run an OT environment, we recommend a separate OT security programme with its own governance — an IT cybersecurity manager usually does not cover OT fully.
Part Three
Transitional and final provisions
§ 28
Transitional provisions
¶
A period (roughly 1 year) to bring existing systems, documentation and processes in line with the decree. Until then the previous rules apply.
CypherOn note
If you were regulated under the old Decree 82/2018 Coll. (repealed by § 72 of the act), you have a transitional period to put the new measures from 409/2025 in place. Update your internal documentation and the references in your policies (from 82/2018 to 409/2025) and plan a gap analysis against the new structural changes.
The decree takes effect on 1 November 2025.
CypherOn note
Together with Act No. 264/2025 Coll. and Decree No. 410/2025 Coll. (lower regime). The deadlines for putting the measures in place come from § 13 para. 4 of the act (1 year from registration) and from § 28 of this decree.
Annexes
Annexes to the decree
Annex 1
Asset valuation
¶
Methodology for setting the levels (classification) of primary and supporting assets by confidentiality, integrity and availability.
CypherOn note
A workable scale for a mid-sized company: C (confidentiality): public / internal / confidential / strictly confidential; I (integrity): standard / high / critical; A (availability): low / standard / high / 24/7. Concrete measures follow from the classification: encryption (C confidential and above = at rest), backup (A high = daily), MFA (C confidential = MFA mandatory). Classify at the level of repositories and categories, not document by document.
Annex 2
Disposal of information and data
¶
Rules and methods for securely disposing of media and data, matching the classification level of the asset.
CypherOn note
For confidential data: cryptographic erasure (rotate the keys and the original data becomes unreadable), physical destruction of the media for the most sensitive material (degausser, shredding). For ordinary data a standard secure wipe is enough (ATA Secure Erase for SSD/HDD). Keep the disposal certificate from your vendor — the auditor will ask how you can demonstrate that you destroyed the data on devices retired 2 years ago.
Annex 3
Vulnerabilities and threats
¶
A reference catalogue of typical vulnerabilities and threats, used when identifying risks under § 8.
CypherOn note
The decree gives you a starting catalogue. In practice extend it with current threat intelligence (CISA KEV, MITRE ATT&CK, advisories tracked by NÚKIB / CSIRT.CZ). We recommend keeping a “top 20” of the threats relevant to your sector and reviewing it every year — the threat landscape moves.
Annex 4
Risk assessment
¶
Methodology for analysing and evaluating risk (likelihood × impact) and setting the acceptable level of risk.
CypherOn note
We recommend starting from the methodology in the decree and adding the principles of ISO 27005. Key dimensions: likelihood (1–5), impact (1–5 — financial, reputational, legal, operational), acceptance criterion (typically a risk score of 12 and above cannot be accepted without approval by the statutory body).
Annex 5
Supplier management — security measures for contractual relationships
¶
A model scope of security clauses and requirements for contracts with suppliers to the regulated service.
CypherOn note
The contract package that belongs in every key supplier contract: definition of an incident, reporting deadline (typically 24 h), content of the report, right to audit after an incident, penalties for failing to report, termination clause, obligations on subcontracting, provisions on handing over data and logs (linked to § 24 of the act). For suppliers outside the EU (transfers of personal data) add SCCs or BCRs.
Annex 6
Topics for security awareness development
¶
Recommended content of training and awareness activities for users, administrators and people in security roles.
CypherOn note
The decree lists the topics — phishing and social engineering, securing devices and passwords, MFA, cloud, e-mail, BYOD, incident reporting, current threats. Standard programmes cover them: KnowBe4, Cofense, the NÚKIB awareness portal. Measure the phishing click rate — the target is under 5 % after 12 months of the programme. Specialised training: developers (secure coding), finance (BEC awareness), management (governance, decision-making during incidents).