Operational security in the energy sector is national preparedness
In energy and other critical infrastructure, the cost of an outage is rarely measured in lost revenue alone. It is measured in what else stops working: water supply, payments, cold chains, care homes. This article looks at the IT/OT boundary, at plant designed to run for decades, at the supply chain, at what NIS2 actually asks of the board, and at what separates genuine preparedness from a preparedness document.
The cost is not measured in revenue alone
In most businesses, the consequence of an outage is counted in money: lost sales, a delayed delivery, a figure that fits in a spreadsheet. In the energy sector the bill does not stop there. When power fails, so do water treatment, payment systems, cold chains, care homes and data centres. The business is one link in a chain where other people's continuity depends on your operations staying up.
That changes what risk means. A loss that is acceptable to shareholders may be unacceptable to society, so risk appetite in critical infrastructure has to be set against a different yardstick than the purely financial one. That is a board decision, not an operational one: which functions must never fail, how long they could be down in the worst case, and what the business is willing to give up to keep them running.
IT and OT are two disciplines sharing one attack surface
Security as it developed in the IT world rests on an order of priority: confidentiality first, then integrity, then availability. In operational technology, such as control systems, SCADA, protection relays and remote control, the order is different. Safety of people and plant comes first, followed by the ability to observe and control the process. A plant that cannot be controlled is dangerous. A leaked document is serious, but rarely life-threatening. Two professional cultures with different priorities now defend the same network, and they often use the same words to mean different things.
The convergence has already happened. Remote metering, predictive maintenance, cloud analytics and supplier remote access have turned the boundary between the office network and the process network into a line on an architecture diagram rather than a physical fact. The question for the board is not whether the networks are separated on paper, but who can actually reach the control systems today, with what privileges, and whether that leaves a record someone reads.
IEC 62443 is the reference standard for industrial automation and control systems. Its most useful idea for a board is a simple one: divide the plant into zones according to consequence, and treat every connection between zones as something that has to be justified, controlled and monitored. That is a model management can ask about without being an engineer.
Equipment built to last thirty years
An office laptop is replaced every four years. A protection relay, a controller or a transformer stays in service for decades. Much of what now forms the attack surface in an energy facility was specified before anyone expected it to be networked. The supplier may no longer exist, and industrial protocols such as Modbus and IEC 60870-5-104 were originally designed without authentication. In practice they trust anything allowed to talk to them.
Nor can the plant be taken offline whenever it suits. Maintenance windows are scarce, and they are governed by season, production obligations and the system operator. A vulnerability that IT closes the same evening may, in OT, have to be carried for the months until the next planned outage. That is not negligence. It is a condition of the industry.
The governance consequence matters. Compensating controls, such as segmentation, strict and time-limited access, monitoring for abnormal traffic and documented manual fallback procedures, are not stopgaps but the primary strategy. Management should therefore ask for something other than a list of missing patches. It should ask to see which risks are being carried deliberately until the next window, who decided to carry them, and what is holding them in check in the meantime.
The supply chain is part of the plant
Critical infrastructure is rarely run alone. System integrators, maintenance contractors, component manufacturers and cloud services hold access, knowledge and often permanent connections into the environment. That route in is both available and built on trust, and it is rarely covered by the operator's own monitoring.
The contract is therefore a security control in its own right. Four questions decide more than the rest of the vendor assessment combined:
- Who holds standing access into the control environment today, and how is it removed the day an engagement ends?
- What triggers notification from the supplier if the supplier itself is compromised, and within how many hours?
- Which subcontractors sit behind the supplier you actually hold a contract with?
- What happens to operations if that supplier is unavailable for two weeks?
The requirement is not new in substance, but it has become explicit. NIS2 lists supply chain security among the risk-management measures an entity must have in place, and ISO/IEC 27001:2022 sets comparable expectations through the supplier controls in Annex A. What both have in common is that accountability stays with the operator. It cannot be delegated away by choosing a large, well-known vendor.
When decision support becomes automated
More and more of the operating picture is assembled by machine: load forecasting, condition monitoring, anomaly detection. Often that is sound engineering. But the model becomes part of how the plant is run, and the same questions then apply as to anything else on site: who owns it, what data is it built on, what happens when it is wrong, and how does the operator see that it is wrong?
Regulation has caught up with this. The EU AI Act treats AI systems used as safety components in the management and operation of the supply of electricity, gas, heating and water as high-risk, with requirements for risk management, data quality, logging and human oversight. ISO/IEC 42001 is the management system standard for artificial intelligence, and it lets an organisation govern this with the same mechanics as ISO/IEC 27001. The practical advice is unglamorous: map which models already influence operational decisions, and establish whether any of them fall into the high-risk category, before somebody else makes that assessment for you.
Norway is not starting from scratch
Norwegian power companies are already regulated on preparedness. The Energy Act and the power supply preparedness regulations impose requirements for physical and digital protection, contingency planning and exercises, and companies form part of the Norwegian power supply contingency organisation (KBO) supervised by NVE. Entities that control basic national functions carry additional duties under the Security Act. NIS2 is EEA-relevant and is to be incorporated into Norwegian law. The directive does not replace this picture; it adds a layer of governance, documentation and management accountability on top of it.
The common mistake is to build a second, parallel regime alongside the one that already exists. What works is to map the overlap once: one set of risk assessments, one plan, one exercise programme and one reporting line to the board, cross-referenced to each regulatory regime. The same documentation then answers several supervisors, and nobody exercises the same scenario twice.
Why NIS2 lands hardest here
Energy sits in Annex I of the directive, among the sectors of high criticality. Large entities in those sectors are classified as essential, medium-sized ones as important, and some are designated regardless of size. The distinction is not cosmetic: essential entities are subject to ongoing supervision, while important entities are generally examined once there are indications of a breach. For an energy company that means the regulator can arrive without anything having gone wrong.
Reporting deadlines are short and run from the moment the entity becomes aware of a significant incident: an early warning within 24 hours, an incident notification within 72 hours and a final report within one month. This is not a job for IT alone. It assumes someone has the authority to judge an incident significant at three in the morning, that they know who has to be told, and that management knows who they are.
Accountability here is formal rather than rhetorical. The directive requires the management body to approve the risk-management measures, oversee their implementation and undergo training itself, and members can be held liable for breaches. For essential entities, a supervisory authority may in cases of serious failure temporarily bar individuals at chief executive level from exercising managerial functions. The practical effect is easy to describe and demanding to meet: when the regulator arrives, explaining what the business does is not enough. It must be possible to document that the board has asked for status, set expectations of management, followed up on findings and treated risk as a recurring agenda item in its own right. Documentation produced in the wake of an incident is rarely persuasive.
Exercises are the only honest test
Most organisations in the sector have a contingency plan. Fewer have tested it under realistic conditions: the IT systems the plan depends on are down, the key person is on holiday, the supplier does not answer at night, the press calls before the situation is understood, and the decision to disconnect a facility has to be taken on incomplete information.
Exercises rarely reveal that the plan is missing chapters. They reveal that decision authority is unclear, that the contact list is out of date, that nobody has settled who speaks to the authorities, and that the leadership team has never practised making a choice where both options are bad. That practice determines how the first hours unfold, and the first hours usually shape everything after them.
An exercise worth the time puts operations and management in the same room, and includes at least one scenario in which the business has to run manually without knowing for how long. That is where you find out whether the fallback procedures have actually been rehearsed, or only written.
Competence at the top is part of preparedness
Roger Ison-Haug has researched the relationship between the number of unwanted cyber incidents and the competence of senior management. Among Norway's 50 largest companies on the Kapital list, one company had executives with formal education in cybersecurity. In the Forbes Global 500, the figure was around ten out of five hundred.
As Ison-Haug puts it, there is a gap between the responsibility carried by senior executives and their actual competence in cybersecurity.
Historically, IT and security were treated as support functions under the finance department. In critical infrastructure, information technology is now a precondition for the business delivering anything at all. Executives are not expected to become technologists. They own the strategic choices and the targets, and they need to be good enough as buyers and reviewers to know what to ask for, what to follow up, and what a good answer looks like.
Berigo works with advisers who have 20 to 30 years of experience from the energy and technology sectors, and who understand both the management system and the plant. Thomas Mørtsell, CSO of the energy group Aneo AS, says Berigo has made it easier to combine regulatory compliance with real operational security across the group. That combination is the point: compliance without operational effect is a cost, and operational security without documentation is hard to defend when someone asks.