A cyber incident cannot always be prevented. Whether a public institution copes with one depends on what it has prepared in advance: who makes the decisions, whom they call, what the supplier contract says and whether the procedures have ever been tested.
These were the common themes of our expert brunch, Cyber Resilience in Public Administration, held in Bratislava on 6 October 2026. The speakers were Štefan Porubčan (Soitron), Martin Lohnert (void SOC) and Pavol Dovičovič of the Cyber Security Competence and Certification Centre (KCCKB). They were joined on the panel by Milan Pikula of SK-CERT, the Slovak national Computer Security Incident Response Team, and Radoslav Zlacký of the National Agency for Network and Electronic Services (NASES). This article summarises the key points, including insights from the discussion that do not appear in the presentations.
Only a few years ago, it might have seemed that a next-generation firewall and good technology were enough. Today it is clear that incidents must not only be prevented and detected – organisations must also assume that one day they will be hit too. When a public institution goes down, the impact is felt not only by the office itself, but also by the citizens who rely on its services.
Prevention, policies, processes and user awareness remain just as important. However, the Slovak Cybersecurity Act and the regulations governing public administration IT also expect institutions to respond to incidents effectively. In his talk, our security expert Štefan Porubčan raised the questions every institution should be able to answer:
The aim is not to avoid incidents at any cost, because that is not realistic. The aim is to handle them without fatal consequences for the institution or for its head.
Attackers mostly strike when we are not at work: at night, at weekends and on public holidays. Yet the law requires an early warning to be submitted within 24 hours, and monitoring is expected to be available around the clock. A single position covering 24/7 operations in fact means employing five or six full-time staff once shifts, holidays and sick leave are taken into account.
Technology will detect the incident. The decision to disconnect a production system, however, must still be made by a person with the authority to do so. That authority remains with the institution regardless of whether it runs its own Security Operations Centre (SOC), a hybrid model or SOC as a service. With an external service, part of the response can be delegated to the provider, but only to the extent agreed in the contract and the service level agreement (SLA).
Before the service goes live, the institution agrees with its SOC provider on the conditions under which the provider may shut down a system, block access or reset identities. At 4:18 am, nobody then needs to be woken up to give approval. Martin Lohnert, Director of our SOC, added an important point: if an incident threatens to escalate into something major, the response should take precedence over operational SLA parameters.
The biggest problem for institutions is usually not technology but people. In-house expertise is scarce, so security is often procured as a service. Pavol Dovičovič of KCCKB, however, reminded us of a fundamental point: the delivery of a service can be outsourced, but the organisation’s accountability cannot. Under the Cybersecurity Act, accountability lies with the head of the institution. In addition, the cybersecurity manager should not report to IT, but directly to the head of the institution.
What can be outsourced?
Not all services are the same. Some institutions need only monitoring, while others need backup, a consultant or an on-call incident response service.
What must remain in-house?
The law and its implementing decree also require supply chain management. The fact that an activity is performed by someone else does not change your obligation to demonstrate compliance. And you must demonstrate not only that the service exists, but also that it works in practice.
A poorly defined need leads to a poorly procured service. Before launching a tender, an institution should know what it actually wants. A SIEM? Monitoring? An in-house team? How will it handle incidents, and how will it integrate the new service into its processes? And how much will it cost?
At the brunch, we heard about an organisation that made a one-off purchase of a one-year service, including licences, only to discover afterwards that it did not cover what it needed. A contract amendment will not solve this; the supplier will most likely either withdraw or raise the price. The solution is to define, at least in outline, what the service must deliver, obtain a cost estimate (for example, from a consultant) and carry out a basic risk analysis: what will the service bring, and what could happen without it?
In public procurement, price is often the main criterion. The lowest price, however, does not mean the lowest risk. Requirements must therefore be set before bids are evaluated; otherwise, there is nothing to base the decision on.
Scope matters most. The sentence “The supplier will provide security monitoring” is not a service specification. What is monitored, and when? What counts as an incident? Whom does the supplier contact, and how? A single sentence in a contract can conceal dozens of unanswered questions.
An SLA alone is not enough. You also need measurable key performance indicators (KPIs) and key risk indicators (KRIs). For example: 99.9% service availability, triage of a critical alert within 15 minutes or escalation of an incident within 30 minutes.
Be on your guard if you hear:
Outsourcing is not a one-off purchase. The service must be managed throughout its life cycle, because infrastructure, risks, legislation and the supplier itself all change. Requirements that were adequate at signing may no longer suffice two years later.
Well-structured outsourcing follows a clear sequence: need, supplier risk analysis, requirements, selection and contract. This is followed by a repeating cycle of operation, oversight and change, until a possible exit.
Oversight rests on regular reporting, evaluation of agreed parameters, review of incidents and escalations, and audits. A monthly report full of figures without context says nothing about the quality of the service. It is therefore worth agreeing in the contract that reports will also include, for example, explanations and a comparison with the previous period. Management should be able to see from them:
During an incident, there is no time to knock on one door after another. Panellists from SK-CERT, NASES and void SOC explained who does what, and what can be expected from whom.
With ransomware, one essential rule applies: get in touch immediately. When an organisation reaches out at the start of an attack, SK-CERT can advise it effectively. When it reaches out after three days, it is probably too late.
And what if something goes wrong during the response? The panellists agreed that effective cooperation rests on agreements made in advance. A commercial SOC does not intervene arbitrarily; the client approves the scenarios when the service is defined. NASES intervenes only within the scope agreed in advance and for which it has a mandate. Liability for damage can be limited by contract or insured, but ultimately it remains with the institution.
Asked what participants should take away from the brunch, the panellists agreed on three words:
Cyber resilience is not a product an institution can buy. It is a capability that must be built, tested and maintained – with or without suppliers.
Not sure where your institution stands today and what it should tackle first? Get in touch – we would be happy to talk.
We are in the process of finalizing. If you want to be redirected to our old version of web site, please click here.
