Risk-Based Cyber Protection: What Resolution No. 1470 Changes for Critical Infrastructure Operators (2026)

A critical infrastructure operator — that's how Cabinet of Ministers Resolution No. 1470 defines the entity whose cyber protection rules changed on November 20, 2025. No press conference, no headlines, but very real consequences for a security team's daily work: the General Requirements for cyber protection of critical infrastructure objects were rewritten, and the core shift is a move away from a static "do this, do that" checklist toward a model built on cybersecurity risk management.

Under the old rules, a critical infrastructure operator mostly worked through a fixed list of requirements and then waited quietly for the next inspection. Now it has to continuously assess its own risks, document a target state of cyber protection, and review its action plan every year — which sounds a lot like what an information security management system under ISO/IEC 27001 already requires, a standard we've covered in detail in our complete ISO/IEC 27001 certification guide. That overlap isn't a coincidence, and it's what this article is about.

We won't walk through the resolution clause by clause here — the full text is already available on Parliament's website. Instead, we'll look at what the risk-based model means in practice for a critical infrastructure operator, where it genuinely mirrors ISO/IEC 27001's logic, and why calling Law No. 4336-IX "Ukraine's NIS2 law" is an oversimplification worth correcting.

Cabinet of Ministers Resolution No. 1470 of November 13, 2025 doesn't create a new regulation from scratch — it amends Resolution No. 518 of June 19, 2019, and restates the General Requirements for cyber protection of critical infrastructure objects in a new edition. There's a telling detail even in the title: the words "requirements FOR cyber protection" became "requirements ON cyber protection" — a small change for a lawyer, but a signal that the document now describes an ongoing process rather than a one-time bar to clear. The amended resolution took effect on November 20, 2025. We've laid out the timeline of the event and its business impact separately in a news piece on critical infrastructure cyber protection moving to a risk-based model.

The State Service of Special Communications spelled out the new model's logic in an official explainer: operators now secure their objects through measures that account for the results of cybersecurity risk management, not a fixed checklist. The algorithm runs in three sequential steps.

Step one is assessing the current state: the operator records exactly where its cyber protection stands right now, no sugarcoating. Step two is setting targets: based on risk management results and a single catalog of cyber protection measures maintained by the State Special Communications Administration, the operator defines its target, desired state of protection. Step three is implementation: the operator builds a phased action plan and records it in a cyber protection plan, which it must review every year and, if needed (say, if the risk level changes), update off-cycle.

One detail is easy to misread, so let's call it out directly: switching to the risk-based model doesn't cancel the mandatory baseline cyber protection measures. They stay mandatory for every operator without exception — the risk-based approach defines what to do on top of that floor, not a replacement for it.

Under the updated General Requirements, a critical infrastructure operator is an entity that operates a critical infrastructure object (CIO); the resolution also names owners and administrators of critical information infrastructure objects alongside it. The resolution just calls them "subjects" collectively, and they carry the full weight of the new model: assessing the current state, setting targets, maintaining a cyber protection plan, and reviewing it annually.

But there's a category of business these General Requirements don't cover, and mixing that up costs a security team real time. The resolution explicitly excludes the National Bank, banks, other financial-services-market participants supervised by the NBU, and payment-system operators and technology payment-service operators. A separate document covers them instead: National Bank Board Resolution No. 69 of June 27, 2025, "On Critical Infrastructure of the Financial Sector," which took effect on July 8, 2025, and sets its own methodology for identifying critical infrastructure objects, criticality categories, and security passports, running in parallel with Resolution No. 1470, not on top of it.

There's another layer worth knowing about: sectoral bodies responsible for critical infrastructure protection can build their own sector-specific cyber protection requirements on top of these General Requirements and the measures catalog, tailored to a given industry, such as energy, transport, or telecom. Those sectoral add-ons need sign-off from the State Special Communications Administration, so a critical infrastructure operator should check whether its sector already has one instead of relying only on the resolution's general text.

The practical takeaway is simple: before building a cyber protection plan under the new model, a critical infrastructure operator needs to confirm which regulator it actually answers to, the State Special Communications Service or the NBU. Companies that mistakenly try to satisfy both regulators at once usually just end up duplicating work.

If you've ever implemented ISO/IEC 27001 certification, the new model's three steps (assess the current state, set targets, plan the measures) will sound painfully familiar. That's not a coincidence in terminology. It's the same risk management cycle the standard has required since its risk assessment clauses. Here's how the two map directly onto each other:

The difference isn't in the logic. It's in the legal status of the result. Resolution No. 1470 requires a critical infrastructure operator to build a cybersecurity risk management process and document it. An ISO/IEC 27001 certificate is independent confirmation from an accredited body, Bureau Veritas, for example, whose partner Ekontrol has been in Ukraine since 2014, that this process doesn't just exist on paper; it actually runs. An energy or telecom operator that's already been through an ISO/IEC 27001 certification audit typically just translates its existing risk register into the resolution's terminology instead of building one from zero.

That doesn't mean an ISO/IEC 27001 certificate automatically satisfies Resolution No. 1470 — legally, they're two different documents with two different purposes, and neither formally cancels out the other. But an operator starting from zero still gets a strong argument either way: building the system around ISO/IEC 27001 from day one means the resolution's requirements get met as a side effect, not as a separate project.

The second document people often mention in the same breath as Resolution No. 1470, sometimes shortened to just "the cybersecurity law," is Law of Ukraine No. 4336-IX of March 27, 2025, "On Amendments to Certain Laws of Ukraine Regarding the Protection of Information and Cyber Protection of State Information Resources and Critical Information Infrastructure Objects." Parliament passed it on second reading on March 27, the President signed it on April 17, and it took effect on April 20, 2025.

The law amends five underlying laws at once: on cybersecurity, on information protection in information and communication systems, on the State Special Communications Service, on standardization, and on public electronic registers. The most practically visible change is dropping the outdated Complex Information Protection System (KSZI) in favor of risk-management measures maintained throughout a system's lifecycle based on security profiles, the same logic as Resolution No. 1470. The law also sets up a national cyber incident response system, mandatory cybersecurity officer positions at government bodies and critical infrastructure objects, and a cyber protection assessment system that includes an audit component.

And here's where it's worth setting the record straight: Law No. 4336-IX gets called "Ukraine's NIS2 law" in popular coverage fairly often, and that's an overstatement. The State Special Communications Service phrases it more carefully: the law contains provisions that help implement specific norms from European cybersecurity directives on incident response team functions, cyber incident reporting practices, and risk management. That's a partial alignment of specific practices, not a full transposition of the NIS2 Directive into Ukrainian law. Bringing Ukraine's critical infrastructure regulation into full alignment with NIS2 remains a separate, still-unfinished strand of work under EU integration, and a critical infrastructure operator should keep the two apart when an EU partner asks specifically about NIS2 compliance.

The resolution doesn't hand you a step-by-step manual. It gives you a framework. In practice, a critical infrastructure operator starting from scratch, or updating existing compliance, follows roughly this path.

• Record your current state. Inventory the information, electronic communication, and technological systems that belong to your CIO, and describe honestly which cyber protection measures actually work and which exist only on paper.
• Run a cybersecurity risk assessment. The resolution explicitly requires ongoing risk management: organizing the process, assessing risks, minimizing them, monitoring and reviewing their relevance, and exchanging risk information with other subjects. The State Special Communications Administration sets the risk assessment methodology.
• Check the catalog of cyber protection measures. Using the catalog and your risk assessment results, define your target state: the measures your specific object actually needs, not some generic "typical enterprise."
• Document your cyber protection plan. The plan has to line up with the object's protection plan for the "cyberattack/cyber incident" national-level design threat, agreed as part of the critical infrastructure object's security passport.
• Assign an owner. The resolution requires a cyber protection lead or a dedicated unit responsible for measures, risk management, and incident response. You can't leave the role formally vacant.
• Plan for team training. The resolution requires regular staff cyber protection training, differentiated by job responsibilities. A once-a-year, check-the-box briefing doesn't meet that bar.
• Budget against your risk assessment results. The resolution explicitly ties cyber protection spending and financing to risk management outcomes, not to whatever figure carried over from last year's budget.
• Plan for annual review. A cyber protection plan isn't a one-and-done document: you review it every year and update it off-cycle whenever the risk level changes.

Each of these steps sounds like routine administrative work on its own. Together, they add up to what ISO/IEC 27001 calls an information security management system, which is exactly why an operator working through this systematically, rather than for a checkbox, should eventually consider formal certification: it turns internal compliance into a document you can hand to a customer, an investor, or a regulator without a long explanation.

We're already seeing the same handful of mistakes from operators who've just started adapting to the new model.

The most common mistake, and the most dangerous one. The resolution names baseline measures as mandatory for every operator without exception, regardless of what the risk assessment shows. The risk-based approach defines what to do on top of that floor; it doesn't replace it.

Banks, payment-system operators, and other market participants the National Bank regulates follow NBU Board Resolution No. 69, not the State Special Communications Service's General Requirements. Time spent on the wrong document doesn't transfer.

The resolution explicitly requires an annual plan review, plus an off-cycle update whenever needed. A company that prepared a plan for an audit and never revisited it is technically in breach by the second year.

"It's all up to us now" is a common and wrong reading. The operator still has to document decisions, align its cyber protection plan with the object's security passport, and go through cyber protection status assessments. The flexibility is in choosing measures for specific risks, not in whether you report at all.

None of these mistakes come down to a lack of resources. Mostly, they come down to reading the document selectively instead of in full.

Ekontrol has supported ISO/IEC 27001 certification as Bureau Veritas's partner in Ukraine since 2014, and critical infrastructure operators who need to satisfy Resolution No. 1470, not just collect a certificate for a tender file, make up a growing share of our clients.

The assessment starts with a comparison: how well does the company's current cyber protection state hold up against two frameworks at once, ISO/IEC 27001's Annex A and the cyber protection measures catalog maintained by the State Special Communications Administration. That gives a critical infrastructure operator one process instead of two overlapping ones: a risk register, a Statement of Applicability, and a risk treatment plan that satisfy the resolution and lead to an independent certificate at the same time.

If your company is a critical infrastructure operator and needs help moving to the risk-based model, the details on ISO/IEC 27001 certification and a form for a first consultation are both on our site.