Cyber Incident Response in Ukraine: The Role of CERT-UA and ISO/IEC 27001 Controls (2026)

Every company runs into a cyber incident sooner or later. A phishing email an accountant opened. Ransomware that took down the file server overnight before Monday. An admin account someone suddenly logs into at 3 a.m. from another country. The question isn't whether this will happen, but what your team will do in the first hours after it already has.

A cyber incident is an event that has already compromised the confidentiality, integrity, or availability of your data or systems: a breach, a hack, a service outage, unauthorized access. You build cyber defenses to make such events rarer. But no defense gives a hundred-percent guarantee, so alongside preventive measures a company needs a rehearsed response procedure: who does what once the system is already broken into, and when CERT-UA should be brought in.

Cyber incident response follows a logic from the first signal to the takeaways: spot the attack, assess it, contact CERT-UA if needed, contain the damage, and close the gap so the same scenario doesn't repeat. Below we walk through each stage, and next to each one we place the control from the standard covered in our complete guide to ISO/IEC 27001 that makes that stage mandatory rather than forgotten in a panic.

CERT-UA stands for Computer Emergency Response Team of Ukraine. It isn't a standalone agency but a team within the State Service of Special Communications and Information Protection, acting under the Law of Ukraine "On the Basic Principles of Ensuring Cybersecurity of Ukraine." In plain terms, these are the people you call when something has gone wrong at the state or critical level, and who help you make sense of the attack.

The team's functions are listed directly on the official CERT-UA website: responding to and investigating cyber incidents, monitoring and detecting threats, gathering and analyzing attack data, providing help and recommendations, and international cooperation. CERT-UA works with enterprises, institutions, and organizations regardless of ownership form, so a state registry and a private IT company can both reach out.

For businesses, the value of CERT-UA isn't only that you can report to them after a breach. The team publishes indicators of compromise for specific attack waves, warnings about active campaigns, and cyber-hygiene recommendations, free intelligence you'd be foolish to ignore. This is especially true for IT and SaaS companies, which become a frequent target precisely because they hold customer data.

Response isn't a single action but a cycle of several stages. International methodologies and CERT-UA's own practice describe it similarly: preparation, detection, assessment, containment, recovery, lessons. ISO/IEC 27001 doesn't name these stages with the same words, but its controls map onto the cycle almost one to one. Here's how they line up.

Next we go through these stages one by one, with the emphasis on the two where things break most often: timely detection and the decision on whether to notify CERT-UA.

The most expensive incidents aren't the most technically complex ones. They're the ones that go unnoticed the longest. An intruder sitting quietly in the network for months does far more damage than one caught within an hour. So the first practical stage of response is the ability to see that something is wrong at all.

Basic cyber defense here means simple things: collecting logs from key systems, alerts on anomalous logins, antivirus and EDR events, and reacting to user complaints about strange email or file behavior. Without this, a company learns about an incident from a customer or, worse, from the attacker with a ransom demand.

This is where control A.6.8, information security event reporting, kicks in. Its point is simple: any employee should know where to report a suspicious email or a missing laptop within five minutes, and be sure they won't be punished for it. A "I won't say anything, I'll get blamed" culture kills response before it even starts, and no technology makes up for that.

The trick here is to avoid two extremes. Neither the panic of "we'll be fined if we don't report every spam message," nor the complacency of "we're a private company, this doesn't concern us at all." Reality sits in the middle, and it depends on who you are by status.

The obligation to inform CERT-UA about cyberattacks and cyber incidents is set directly for critical infrastructure facilities: energy, banks, telecom, transport, certain state registries. For some categories, such as cloud and data-center providers, the reporting procedure is spelled out in separate Derzhspetszviazku acts, down to an approved form with TLP marking. If your company is part of critical infrastructure, notification isn't a goodwill gesture but a requirement.

If, on the other hand, you're an ordinary business without that status (a run-of-the-mill online store, an agency, or a product IT company), there's no general obligation to report every incident. This is worth saying honestly: the regulations don't require just any business to report to CERT-UA simply because an incident occurred.

Even when reporting is voluntary, it's often worth doing: the team can tell you whether it's part of a wider campaign, provide indicators of compromise, and help you get your bearings on recovery. The basic channel is simple: an email to incidents@cert.gov.ua describing what happened, when, and on which systems. The team explains when and to what extent this is appropriate in its own guide, when and how to contact CERT-UA. The more detailed the description (time of detection, signs, actions taken), the faster and more useful the reply.

Keep one boundary in mind. A personal data breach is a different legal domain than a technical cyber incident. It's reported not to CERT-UA but to the Ukrainian Parliament Commissioner for Human Rights, and it's governed by a separate personal data protection law. CERT-UA may support the technical side of the attack, while responsibility for people's data is your relationship with the Ombudsman. A single incident sometimes demands both actions at once.

Once an incident is confirmed, the most nerve-wracking part begins: the first hours. The goal is twofold: stop the spread and don't destroy the evidence while doing it. These two goals often conflict, which is exactly why you should think them through before the attack, not during it.

A minimal order of actions at the containment stage looks like this:

• Isolate, don't blindly power off. Disconnecting an infected machine from the network beats abruptly cutting its power: some evidence lives in RAM and vanishes on shutdown.
• Save the logs before rotation overwrites them. This is control A.5.28, collection of evidence: logs, disk images, and copies of suspicious emails, gathered so they hold up in both an internal investigation and, if needed, with the police.
• Change compromised credentials. Passwords, keys, and tokens that may have reached the attacker only become safe once replaced.
• Record time and actions. Who did what and when: a simple event log saves you at the lessons stage, when the details have already blurred.

Recovery means restoring systems from clean backups, not a hasty "we brought it back the way it was." Control A.5.26, response to incidents, calls for managed actions following a predefined procedure, not the heroic improvisation of one admin who alone knows where everything sits. And if that admin is on vacation (and they're always on vacation at exactly these moments), the procedure has to work without them. A backup you've never once tried to restore isn't a backup, it's a hope.

The most common mistake after an incident is to exhale, restore operations, and forget. The attack was fought off, the service is back up, everyone's tired, so what more is there to review. Yet this is exactly where the difference hides between a company that gets breached the same way again and one that doesn't.

Control A.5.27, learning from incidents, requires turning every serious case into concrete changes. Not a report for show, but answers to simple questions: how did the attacker get in, why didn't we notice it right away, what in our processes allowed it, and what exactly are we changing. The result is updated rules, new alerts, and sometimes retraining for the people who clicked what they shouldn't have.

In an information security management system this stage closes the cycle: the lessons from an incident feed back into risk assessment, and from there into a review of controls. That way response stops being a chaotic reaction and becomes part of ongoing cyber defense. That's the difference between "we have antivirus" and "we have a system."

Information security incident management in ISO/IEC 27001:2022 is covered by six Annex A controls. They don't write your procedure for you, but they define the list of what has to exist and work in the first place. Here they are in plain language:

• A.5.24: planning and preparation. Roles, responsible people, communication channels, and response plans defined in advance, not invented during the attack.
• A.5.25: assessment and decision. There are criteria that separate a minor event from a real incident, and it's clear who decides on escalation.
• A.5.26: response. Actions follow a documented procedure, and improvisation is kept to a minimum.
• A.5.27: learning from incidents. Lessons turn into changes in the system rather than settling into a forgotten report.
• A.5.28: collection of evidence. Logs and artifacts are stored so they carry weight both in an investigation and in court.
• A.6.8: event reporting. Every employee knows how and to whom to report a suspicion, quickly and without fear of punishment.

Together these six controls give what no single tool does: predictability. An ISO/IEC 27001 certification audit checks not whether you have pretty policies in a file, but whether the company actually knows what it will do at 3 a.m. on a Sunday. We covered the full set of the standard's requirements and the implementation stages in our ISO/IEC 27001 guide.

A quick self-check. If the answer to most points is "yes," your company will respond rather than panic:

• There's a current list of people responsible for response, with numbers that work at night too.
• Employees know one channel to report a suspicious email or device within a minute.
• It's defined what counts as an incident and who decides on escalation.
• Backups of key systems exist, and you've tried restoring them at least once.
• It's written down when to contact CERT-UA and when to contact the Commissioner for Human Rights about personal data.
• Logs are kept long enough that there's something to analyze after an incident.
• After every serious case, a short review is held with concrete changes.

If half the points are left unanswered, that's not cause for shame but a to-do list for the coming month. And almost every one of them is one of the ISO/IEC 27001 controls, not separate paperwork for its own sake.

Response deals with what has already happened. To know what to prepare for in advance, see which information security threats actually hit Ukrainian business.

Ekontrol supports preparation for ISO/IEC 27001 as part of its information security practice. Incident response here isn't a separate service but part of the system: during a preliminary readiness assessment, the team looks at whether you have the plans, roles, and channels required by controls A.5.24–A.5.28 and A.6.8, and where the real gaps are that you don't yet know about.

Then comes implementation: the response procedure, the process for contacting CERT-UA for those legally required to, the boundary with personal data breach reporting, evidence collection, team training, and a scenario rehearsal. For IT companies working with EU and US clients, it's also a ready answer on the security questionnaires where the incident response question comes up almost every time.

If you want cyber incident response at your company to rest on a procedure rather than luck, the details on ISO/IEC 27001 certification and a form for a first consultation are on the site. You can also write to our team directly to discuss where to start. Ekontrol has worked as a Bureau Veritas partner in Ukraine since 2014.