NIS2 in Croatia is not solved by a document shown when an enquiry arrives. Cybersecurity needs to become an operational plan that connects important business services, accountable people, security controls, and evidence that those controls are performed. The first step is not buying another tool. It is establishing scope, priorities, and the decisions an organisation must be able to make when a system, supplier, or process fails.
Croatia's Cybersecurity Act regulates the categorisation of key and important entities, cybersecurity requirements, authorities, and supervision. At European Union level, the core source is Directive (EU) 2022/2555 . The legal assessment of applicability and obligations should be confirmed with competent legal and security professionals. This article provides an operational framework, not legal advice.
A list of servers, applications, and user accounts is not enough to manage risk. A business service commonly depends on people, data, applications, devices, external suppliers, and locations. When a customer cannot submit an order, production cannot receive a work order, or finance cannot access documents, the impact is not limited to the IT department.
It is therefore useful to first describe the services the business must keep available. Examples may include receiving orders, production planning, payroll processing, invoicing, or access to documentation needed for delivery.
For each important business service, record:
This record gives management a concrete decision object. Instead of the general question of whether security is good enough, it can decide how long delivery may stop, which process is restored first, and which risk it accepts while an additional control is being introduced.
For organisations that are addressing processes, ERP, and responsibilities at the same time, ERP and process screening can help structure an initial review of services, dependencies, and owners. The aim is not to create another inventory, but to align the technical record with how the business actually operates.
The NIS2 Directive and the Croatian legal framework do not require the same process or the same scope of activities from every organisation. Before preparing a plan, an organisation should verify whether the framework applies to it, under which category it may be considered, which authority is competent, and which obligations apply in its specific case.
This assessment should not remain an informal assumption made by the IT team. It should record who performed it, which information it relies on, and when it needs to be reviewed again. Organisations change: growth, a new service, a supplier change, or a changed role in the supply chain can alter the assessment.
An operational plan can begin before the final legal assessment is complete. Mapping important services, access, suppliers, and recovery is useful regardless of the final regulatory scope. However, a final conclusion on compliance should not be drawn from an internal operational review alone.
A sentence such as "access is granted on a need-to-know basis" describes an intention, but it is not a security control. A control exists when it is known who requests access, who approves it, how long it remains valid, where it is recorded, and how it is removed after a role change or departure.
The same principle applies to backups, vulnerability management, incidents, continuity, and suppliers. For each area, define four elements:
For example, management and the process owner can approve the list of critical services and recovery priority. The system owner can retain an access request, approval, and record of periodic review. For incidents, an appointed incident lead can maintain a record of an exercise, decisions made, and lessons learned. For continuity, management and operations can review the result of a recovery test and decide whether identified deviations are acceptable.
This approach changes the conversation. The question is no longer whether a policy exists, but whether the organisation can show that a control was performed and that someone acted when it was not.
A cloud service, external development team, accounting service, ERP maintenance provider, or device manufacturer can all be part of the same business service. A contract does not remove that risk by itself. If a supplier loses availability or is compromised, the organisation still needs to know what happens to data, the process, and recovery.
For suppliers connected to important services, check:
The depth of review does not need to be the same for every contract. A meeting-booking tool and a system without which production stops do not have the same business impact. Assessing potential interruption or compromise helps the team direct time to the areas where failure would stop a critical service.
Security controls weaken over time. People change roles, suppliers change their service, systems gain new integrations, and the document remains unchanged. A one-off project is therefore not the same as operational capability.
The plan should include a calendar that does not depend on someone remembering. The rhythm may include:
The exact schedule depends on the organisation, available resources, and service criticality. What matters is that each activity has an accountable person, an expected output, and a decision that follows from the findings. A recovery test, for example, is not complete simply because it was started. The organisation needs to record whether the service was restored within an acceptable timeframe, which prerequisites were missing, and who approved the next actions.
Assume production depends on ERP work orders, network infrastructure, an external maintenance provider, and inventory data. If ERP is unavailable, the process owner needs to know whether work can continue manually, how long that mode can last, and who decides when the recovery priority changes.
In this case, the operational plan does not need to start with a technical list of every component. It can start with several verifiable questions:
The answers expose gaps that policy alone often does not reveal: an unclear priority, access that depends on one person, a supplier without an agreed reporting route, or a backup whose restoration has not been tested.
An operational framework does not replace legal assessment, technical security analysis, or decisions by competent authorities. More records also do not automatically mean more security. Documentation without real performance can conceal a problem, while too many forms can slow down the people who need to respond.
The purpose is to establish proportionate control: clear enough to be performed and sufficiently evidenced for management to assess the situation. Risks are not all equal, and neither are all measures feasible at once. Management needs to decide which risks are reduced first, which are accepted temporarily, and when the decision will be reviewed again.
To begin, select one important business service and check whether it has an owner, acceptable downtime, a list of key dependencies, a way of working during interruption, and evidence of the latest recovery test. This small, verifiable review can become a template for other services.
Where business processes and systems are connected, Connected operations can help frame the discussion between operations, finance, production, and IT. The final assessment of NIS2 compliance and applicable obligations should be confirmed with appropriate legal and security professionals.