By Mourtaza Moise Fazlehoussen, Founder and CISO, FORTEIA
At 7.40 on a Monday morning, the managing director of a European machinery manufacturer receives a call from the factory. Production orders are inaccessible. The dispatch team cannot confirm which deliveries can leave. A maintenance supplier’s remote access account appears to have been compromised, and the IT team is isolating affected systems.
By nine o’clock, the leadership team is around a table. The finance director wants to know how long operations will be interrupted. The operations director asks whether restarting production is safe. A major customer needs an answer before noon.
The managing director turns to the IT manager. “We approved the security budget. What are we missing?”
The company has backups, endpoint protection and a security policy. Its last management dashboard showed mostly green indicators. Yet nobody can say how quickly the order system can be restored, who can authorise emergency expenditure, or whether the supplier still has another route into the network.
This imagined incident captures the leadership problem behind NIS2. A business can invest in cybersecurity and still leave crucial decisions unresolved. Those decisions become painfully visible when normal operations stop.
Why This Lands on the Leadership Table
NIS2, the European Union’s updated cybersecurity directive, sets risk-management and reporting requirements for covered organisations across more sectors. Applicability depends on activity, size, exceptions and national implementation, so leaders should confirm their position rather than assume they are covered.
For organisations in scope, Article 20 places approval and oversight of cybersecurity risk-management measures with the management body, here the managing director and board, and provides for training and possible liability, subject to applicable law.
The financial exposure is conditional. National law must allow maximum fines of at least €10 million or 2% of worldwide annual turnover, whichever is higher, for essential entities, and at least €7 million or 1.4%, whichever is higher, for important entities. These are minimum levels for the maximum fines, not automatic penalties for every breach.
Leaders need enough understanding to challenge assumptions, fund priorities and follow up on unresolved risks. Technical work can be delegated; management must remain accountable for decisions on how much disruption the organisation will tolerate.
Can We Actually Recover?
Backups have completed each night, but nobody has rehearsed restoring the full order-to-dispatch process with the people who use it. The dashboard measured whether copies existed. Management needed to know whether the business could resume work.
Article 21 covers business continuity, backup management, disaster recovery and crisis management, and calls for procedures to assess whether they work. Leaders should ask for recovery exercise results, including what failed and who will fix it.
Someone must also confirm that orders are complete, schedules are reliable and staff can operate the recovered service. The operations director should accept the recovery result; leaving that judgement to IT overlooks the business consequences of inaccurate data.
Who Controls Supplier Access?
The maintenance supplier’s access was approved months earlier to fix an urgent fault and never removed. Procurement assumed IT reviewed it. IT assumed the factory manager still needed it. The factory manager assumed the supplier’s security was sufficient.
NIS2 explicitly includes supply-chain security. The weakness here is a relationship with no owner. The manufacturer needs a named person to approve continued access, a review date, a reliable way to revoke it, and contracts that support timely incident communication.
Suppliers outside NIS2’s direct scope are not automatically subject to it, but customers may still ask credible questions about access and recovery.
Reporting While Facts Are Still Emerging
Meanwhile, a reporting question emerges: is this a significant incident, and who decides? Under Article 23, an incident is significant if it has caused or is capable of causing severe operational disruption or financial loss to the entity, or considerable material or non-material damage to others.
The clock runs from becoming aware of a significant incident, not from a later management decision to classify it. If the organisation becomes aware by mid-morning on Monday, the general sequence is an early warning within 24 hours (by mid-morning on Tuesday) and an incident notification within 72 hours, both without undue delay. A final report is due within one month of the incident notification. If the incident is still ongoing at that point, a progress report is required instead, followed by a final report within one month of handling the incident.
At the manufacturer, nobody knows who may send the early warning, or who would act if the managing director were unavailable. The managing director asks for certainty before anyone communicates externally, and the IT manager cannot yet provide it.
The lesson is to settle the process in advance: who assesses significance, records when the organisation became aware, coordinates the facts and submits notifications. A rehearsed process helps a team separate confirmed facts from open questions and decide in time, because the plan must accommodate uncertainty.
How the Week Ended
Production restarts on Tuesday afternoon, about a day and a half later than hoped, after operations has checked the recovered orders by hand. The early warning goes out the same afternoon, after the deadline has passed. The major customer receives a revised delivery plan, rather than the confident answer it wanted on Monday.
Several weeks later, the board reviews what happened. Rather than commissioning another policy or buying another product, it assigns owners to the failures the incident exposed and agrees how progress will be shown. The next recovery exercise will include operations, supplier access will be reviewed, and deputies will be appointed for incident decisions.
The board also changes its reporting. Alongside technical indicators, it asks which critical services have been tested, which weaknesses remain unresolved and which decisions need management approval. A red indicator becomes a reason to examine evidence and allocate resources, not to pressure the security team into a more reassuring slide.
Three Questions to Ask This Week
1. When did we last test full recovery with operations present, and what failed?
2. Who owns each supplier’s remote access, and when was it last reviewed?
3. Who decides whether an incident is significant, and who is the named deputy?
At the next meeting, the managing director returns to the question that went unanswered that Monday morning. “If our order system becomes unavailable again, what can we confidently tell our customers?”
This time, the operations director has a tested recovery result, the limitations are recorded, and the outstanding work has an owner and a deadline. That is the kind of answer business leaders should expect from their cybersecurity programme.
Source note
Legal references are to Directive (EU) 2022/2555, particularly Articles 2 and 3 (scope), 20 (governance), 21 (risk management), 23 (reporting) and 34 (penalties). National implementing legislation and relevant sector-specific rules should be checked for the organisation concerned. The operational recommendations and fictional narrative are the author’s commentary.
Official text: https://eur-lex.europa.eu/eli/dir/2022/2555/oj
Latest News
