At 08:20, a Norwegian distributor cannot access its order system. Several employees receive unusual sign-in requests. Vehicles are waiting, customers expect deliveries, and the IT provider cannot yet confirm whether the cause is an attack. The CEO has decisions to make before anyone has a complete explanation.
This is a hypothetical exercise. Its purpose is to expose the choices that a technical recovery plan cannot make for management: what can safely continue, which customers need attention, and who can authorize exceptional spending or a prolonged interruption.
Establish one decision process
Appoint an incident coordinator with a named deputy, and separate coordination from technical investigation. In a small company, the CEO may coordinate initially, but should avoid becoming the only person through whom every update passes. Use a prearranged alternative communication channel if normal email or collaboration accounts may be compromised.
Ask for a short situation note with four fields: confirmed facts, working assumptions, immediate consequences and the next decision. Record decisions, owners and times. Do not turn an unverified explanation from a supplier into a public statement.
NSM's incident checklist, updated on 1 October 2026, recommends activating prepared plans and obtaining incident-response expertise. Technical containment and preservation of evidence should follow those plans and qualified advice. Management should explain operational dependencies rather than improvise system commands.
Decide which service can continue safely
In the distributor's exercise, some deliveries may be prepared from previously verified orders. Others depend on changed addresses or payment details that cannot currently be trusted. Continuing all shipments could spread the consequences. Stopping everything could unnecessarily harm customers.
Ask the operations owner to propose a minimum service: which orders can be verified independently, which must wait, and how manual work will be reconciled later. Consider safety, contractual consequences and customer dependence before simply prioritizing the largest invoice. Keep an auditable record of manual orders to avoid duplicates when systems return.
Make the financial exposure concrete. If ten deliveries are postponed, which costs are deferred and which are additional? Separate possible lost sales, contractual claims, recovery costs and cash-flow effects. A lost day of revenue is not automatically a lost day of profit. Use ranges and identify the assumptions most likely to change.
Communicate what is known and when the next update comes
Give employees one approved route for reporting suspicious activity and one place for operating instructions. Assign customer communication to someone who can coordinate with operations and the investigation. Customers need practical information about their orders, alternatives and the next update, even when the cause remains uncertain.
Avoid claiming that no information was accessed or that recovery will finish by a particular hour without evidence. Contact the relevant response partners and assess reporting obligations promptly. A notice to a customer, a police report and a regulatory notification have different purposes; one does not automatically replace another.
Under GDPR Article 33, incorporated in Norwegian law, a controller must notify the competent supervisory authority of a personal data breach without undue delay and, where feasible, within 72 hours of becoming aware, unless it is unlikely to risk individuals' rights and freedoms. A processor must notify the controller without undue delay. This is not a universal deadline for every IT outage. Assess information to affected people under Article 34, as well as relevant sector and contractual duties. Do not wait for a finished investigation to begin these assessments.
Define recovery in terms of usable service
A server responding again is only part of recovery. Can staff trust the orders, access the correct records and reconcile the backlog? Ask technical responders for the evidence supporting a safe return, and ask operations to verify an end-to-end transaction before broad resumption.
Management decides the permitted operating scope based on that evidence. The board should receive the material business consequences, major uncertainties and decisions requiring its involvement. It should challenge readiness and resource needs without directing individual recovery steps.
Rehearse the uncomfortable choice
Run this scenario as a 45-minute discussion with the CEO, finance, operations and the IT contact. At the midpoint, introduce one new fact: the latest backup has not been successfully restored in a test. Then introduce a customer asking whether its information was exposed.
Finish with three outputs: a corrected contact list available during an outage, the most important unresolved decision authority, and one recovery or manual-work test with an owner and date. This exercise structure is my recommendation, not an official response timeline.
Use the article on outsourced IT accountability to close supplier gaps before the next exercise. For errors originating in an AI agent, the agent-incident guide addresses its queued actions and connected tools.
Sources and scope
Sources checked on 12 October 2026. The incident and exercise are hypothetical. NSM provides security guidance; specific legal obligations depend on the organization and incident. This article supports leadership preparation and does not replace a technical response plan or an incident-specific legal assessment.