The new Czech Cybersecurity Act one year on: what must be in place in cloud and CI/CD

Where things stand one year in

The new Cybersecurity Act (zákon o kybernetické bezpečnosti), through which the Czech Republic transposed the NIS2 Directive, took effect on 1 November 2025. Organizations that met the criteria of Decree No. 408/2025 Coll. on regulated services on that date had 60 days to notify (§ 6(1) of the Act), i.e. until 31 December 2025.

The latest aggregate figure NÚKIB has published dates from February: according to a press release of 11 February 2026, 4,825 entities out of roughly 6,000 expected had notified by 8 February, and those that notified were sent a registration decision. We were unable to find more recent official statistics while preparing this article.

Delivery of the decision starts three deadlines. They are summarized, for example, in this overview of deadlines after the registration decision is delivered, and their wording can be checked directly in the text of Act No. 264/2025 Coll.

Two tiers, two decrees and no “cloud section”

The Act distinguishes between a higher-obligations tier and a lower-obligations tier (§ 8). The content of the measures is set by implementing decrees: No. 409/2025 Coll. for the higher tier and No. 410/2025 Coll. for the lower tier.

The difference is mainly one of depth. The higher tier requires a full information security management system covering risk, asset, change and supplier management, plus audit (§ 3 to § 27). The lower tier has eleven substantive sections (§ 3 to § 13) and fewer specific numbers.

The decrees do not use terms like cloud, container or pipeline. They talk about “technical assets”, “administrators” and “suppliers”. What that means for an Azure tenant or an AWS account is a matter of interpretation. The mapping below is therefore an engineering translation, not a binding NÚKIB interpretation, and where things are open to debate it pays to document your decision.

Identity and access: start with your cloud administrators

Both decrees require unique identifiers, permissions limited to “the level strictly necessary”, separation of user and administrator accounts, and regular access reviews. The lower tier covers this in § 7 and § 8, the higher tier in § 13, § 19 and § 20.

Under § 8(2) of Decree No. 410/2025 Coll., MFA applies to “administrators, users and technical assets”. If you do not yet have MFA everywhere, paragraph 3 temporarily allows authentication with cryptographic keys or certificates. In NÚKIB’s materials on the lower tier, a strong password policy appears only as the third, fallback level.

What this means in practice

• One identity, federated. Access to AWS via IAM Identity Center, to Azure via Entra ID. No shared IAM users, no local accounts in clusters.
• MFA enforced by policy (Conditional Access, SCP), not left optional. Ideally FIDO2 for privileged roles.
• Separate administrator roles with time-limited activation (Entra PIM, time-bound permission sets).
• Root and break-glass accounts kept out of day-to-day operations, with an alert on every use. NÚKIB’s materials mention storing the credentials for these special accounts in a sealed safe.
• Quarterly review of role assignments, with an export kept as evidence. The decree says “regular”; you set the interval yourself.

The contentious point is “technical assets”, i.e. machine identities. Long-lived access keys stored in CI/CD variables are exactly the kind of credential that is hard to keep under control. A reasonable interpretation is to replace them with short-lived tokens via OIDC federation, which also fits the route via cryptographic keys and certificates.

Logging, detection and incident reporting

The minimum content of a log record is similar in both tiers: date and time including the time zone, type of activity, unambiguous identification of the asset and the originating account, and whether the activity succeeded or failed (§ 9(2) of Decree No. 410/2025 Coll.). Cloud control plane audit logs (CloudTrail, Azure Activity Log, Entra ID sign-in and audit logs, the Kubernetes API audit log) contain these fields. The problem usually lies elsewhere: they are not enabled in every account and region, nobody evaluates them, and the default retention is short.

The higher tier requires retention of at least 18 months and synchronized time. In AWS CloudWatch Logs this has a practical catch: retention is chosen from a fixed list of values, and according to the API documentation, 400 days is followed by 545 and then 731 days. 545 days is a few days short of 18 calendar months, so the safe choice is 731.

resource "aws_cloudwatch_log_group" "audit" {
  name              = "/org/audit/cloudtrail"
  retention_in_days = 731   # 545 days is less than 18 months
  kms_key_id        = aws_kms_key.logs.arn
}

The lower tier sets no number. NÚKIB’s materials give 12 months as the recommended period. Write down the retention you choose along with the rationale, because the decree ties it to your “security needs”.

Incident reporting

Under § 16 of the Act, the initial report must be filed no later than 24 hours after an incident is detected. For incidents with a significant impact, a notification follows within 72 hours of detection and a final report within 30 days of the notification. Entities in the higher-obligations tier report to NÚKIB those incidents within the defined scope that originate in cyberspace and where intentional cause cannot be ruled out; entities in the lower-obligations tier report to the National CERT only those of them that have a significant impact on the provision of the regulated service (§ 15).

The technical consequence: within 24 hours you must be able to say what happened. That requires central log collection outside the affected account, alerts routed to specific people, and a runbook stating who files the report. The article on security monitoring and logging covers how to build such a chain in more detail.

Backup and recovery: where the cloud lulls you into a false sense of security

The decrees require backups not only of data but also of “configurations and settings of technical assets”. In the cloud, this means the backup includes infrastructure as code, Terraform state, cluster manifests, identity provider configuration and DNS. A database snapshot without the ability to rebuild the environment around it does not solve recovery.

The lower tier additionally requires setting the priority and order of asset recovery and naming the people responsible (§ 6). The higher tier adds regular testing of backup integrity, availability and recoverability, protection of backups (§ 26), and separation of production, backup, development, test and administrative environments (§ 12).

Vulnerabilities, changes and the pipeline

In § 12, the lower tier requires “applying approved security updates without undue delay”, a register of unsupported technical assets with compensating controls, and regular vulnerability scanning. The higher tier sets a frequency: scanning at least once a year from both the internal and external network, and a penetration test at least once every two years, including before go-live and after significant changes (§ 24).

An annual scan is the legal minimum, not sensible practice for an environment that deploys several times a day. In the pipeline, it makes sense to scan on every build and to scan the running environment continuously.

• Unsupported assets: the register should include Kubernetes versions past end of support, old base images and unpatched runtimes. An overview of dates is on the Kubernetes EOL page.
• Scanning: images and dependencies in CI, registry scanning for images already deployed, cloud configuration checks (Defender for Cloud, AWS Security Hub or an open-source alternative).
• “Approved” updates: the word implies a controlled process. A pull request with review and automated tests is an easy-to-evidence form of approval.
• Change management (higher tier, § 11): protected branches, mandatory review, a record of who deployed what. Git and pipeline history counts as evidence as long as the person making the change cannot rewrite it.
• The pipeline as a privileged asset: a runner allowed to deploy to production effectively has administrator permissions. Least privilege, environment separation and logging all apply to it. The article on CI/CD security summarizes specific measures.

Decree No. 410/2025 Coll. explicitly mentions a supplier’s “secure development practices” in § 3(5). If you supply software to regulated entities, expect to be asked about your development process in contracts and questionnaires, even if you do not provide a regulated service yourself.

Suppliers, the cloud provider and company leadership

Your cloud provider is a supplier. In the lower tier, contracts with suppliers within the scope of § 12 of the Act must include the relevant requirements from Annex 2. In the higher tier, significant suppliers are recorded in a register, and Annex 5 lists termination terms among the required contract elements – in other words, an exit strategy with a transition period and data migration.

You will not negotiate an individual contract with a hyperscaler. In practice, the task is to show that you have assessed the provider’s standard terms, audit reports and certifications against the decree’s requirements and have consciously accepted the remaining risk. How strictly NÚKIB will judge this approach during inspections is not yet clear from publicly available sources.

An exit strategy also has a technical side: infrastructure described as code, data exportable in standard formats, and backups readable outside the original platform. A plan nobody has tried is just a document.

Leadership

Requirements on top management are a security measure in their own right. In the lower tier (§ 4), management appoints a person responsible for cybersecurity, demonstrably completes training, provides resources, reviews the status of the measures and sets the recovery priority of primary assets. According to NÚKIB, penalties reach up to CZK 250 million or 2% of net worldwide annual turnover, and § 58 of the Act also provides for a ban on holding office.

What to do on Monday

A note on proportionality: a lower-tier company with one application and one cloud account does not need a SIEM or a detection team. It needs audit logs switched on, MFA, separated backups and documented responsibilities. Conversely, meeting the decree does not mean a secure environment. An annual vulnerability scan satisfies the section; it will not stop an attacker.

Key takeaways

• The clock starts when the decision is delivered. You have at most one year for both the security measures and incident reporting (§ 13(4) and § 15(4) of Act No. 264/2025 Coll.).
• The decrees are technology-neutral. Translating them into cloud settings is an interpretation that needs to be documented.
• The higher tier has hard numbers. Logs for at least 18 months, a vulnerability scan at least annually, a penetration test at least once every two years.
• The lower tier leaves more up to you. You set log retention and scan frequency yourself, but you must be able to justify them.
• Backups include configuration. Without IaC, state and a restore test, you will not meet the continuity requirement.
• The pipeline is a privileged asset. Access control, logging and change management apply to it just as they do to production.
• Compliance is not security. The decree sets a minimum, not a target state.