What to do during an incident should not be decided by hierarchy at the moment a service has already failed. An incident response plan must define in advance who leads the incident response, who can isolate a system, who assesses business impact and who approves communications. When those authorities are clear, a team can act with incomplete information without unnecessary delay. When they are not, minutes become expensive because of indecision, not only because of the technical failure.
An incident response plan is not a list of phone numbers stored in a folder no one opens. It is a working framework for decisions made when facts are incomplete, systems may be unavailable and pressure rises minute by minute.
In cybersecurity, a technical signal often arrives before the full picture. Someone may notice an unusual login, a permission change, an unavailable service or a message from a partner. The team does not need to prove the entire attack before opening a record and protecting the business. It needs to know who can take the first controlled action.
The most expensive delay is often not technical. It occurs when no one knows whether they may disable an account, disconnect a server from the network, stop an integration or change the order of work.
These decisions have a real business cost. Isolation that is too broad can stop a production order, invoicing or data exchange with a partner. Isolation that is too slow can increase the scope of the problem and make later analysis more difficult. A plan should therefore contain more than steps. It needs to name the decision owner, a backup person and the threshold for escalation.
It is useful to separate at least four responsibilities:
In a smaller organisation, one person may hold more than one role. What matters is that this is explicitly stated and that a substitute is available if that person cannot be reached. A plan that assumes the same specialist will always be available is not a plan for a real incident.
The first objective is not to write the final explanation. It is to create a reliable basis for the next decision and avoid changes that could erase important evidence.
In the first fifteen minutes, the team should:
This list does not replace technical investigation. Its purpose is to reduce confusion. If five people independently send messages, change settings and call external contacts, the organisation will struggle to establish what happened and which decisions have already been made.
The plan should permit rapid isolation, but with known consequences. For example, it may state in advance that the on-call technical owner may temporarily disable a compromised account, while stopping a critical integration requires the business service owner and incident lead. This threshold is not bureaucracy. It prevents a significant business service from being stopped without assessing the consequence, or an apparent threat from going uncontained while approval is sought.
Time frames are not universal deadlines and do not mean every incident is alike. They provide a framework for exercises and for checking whether a decision has no owner. Each organisation should adapt them to its own services, risks, contractual obligations and responsibilities.
The main goal is to confirm the event and preserve evidence. The team needs to decide who leads the incident, which channel will be used and whether initial isolation is justified.
The main goal is to contain spread and understand the initial impact. The team sets priorities for affected systems, assesses whether external support is needed and triggers internal escalation based on business impact.
The main goal is to stabilise operations and communications. In this period, decisions are made about temporary ways of working, the recovery sequence, and the need for notifications and regulatory or contractual assessment.
The main goal is to remove the cause and restore service in a controlled way. The team needs to define the return order, additional controls and monitoring that can confirm the issue is not recurring through the same route.
A technical team can contain an incident well while the organisation still causes harm through contradictory messages. One person, or one clearly defined role, should therefore manage the facts: what is known, what is still being checked, which decision has been made and when the next update will be provided.
There is no need to wait for complete certainty before communicating internally. Confirmed information should be clearly separated from what is unconfirmed. A message such as "we are investigating possible unauthorised access and are currently limiting the affected service" is more useful than silence, and more honest than an early claim that data was not affected.
External notifications depend on the law, the contract, the type of data and the jurisdiction. An incident response plan should therefore include prepared contacts and criteria reviewed by legal and security functions. During an incident, the team should not improvise who speaks to customers, partners, an insurer or a competent authority.
An available backup is not, by itself, a recovery decision. Before returning a system to service, the team should assess whether the cause has been sufficiently contained, whether the selected copy is reliable, whether access credentials have been changed where needed and whether the same path can be reopened.
Recovery should follow business priority rather than technical convenience alone. It may be more important to restore a limited function that enables a critical process than to fully restore a less important system. The business owner should explain the consequence of disruption, while the technical owner should explain risk and dependencies in returning to service. The incident lead then documents the decision and its rationale.
For organisations connecting ERP, manufacturing, accounting and external integrations, this means mapping dependencies before an incident. A process review can show which outage stops the entire order flow and which can be temporarily bridged with a manual procedure. ORKA's approach through ERP and process screening can help structure that discussion around processes, owners and dependency points.
After stabilisation, the team should reconstruct decisions rather than write a story about a perfect response. Useful questions are specific:
The outcome of the review should be a small number of changes, each with an owner and a due date. A list of fifty general recommendations often produces no change. Priority should go to changes that remove an actual ambiguity: an updated contact, a clearer isolation threshold, a tested return procedure or an exercise of the communications channel.
The current professional framework, NIST SP 800-61 Rev. 3 , connects incident response with broader cybersecurity risk management. It can guide planning, but an organisation must still align its plan with its own Croatian legal, contractual and sector-specific obligations.
Run a short tabletop exercise without a technical failure. Tell a small team that an important service is unavailable and that there is suspected unauthorised access. Then ask: who leads the response, who may isolate the system, who assesses business impact, who sends the internal message and what is the recovery priority?
If the answer is not quick and unambiguous, you have found an issue to resolve before a real incident. Record it in the runbook, assign an owner and repeat the exercise after updating the plan.