Key Requirements for NIS2 in the Energy Sector

NIS2 in the energy sector connects cybersecurity with service continuity, operational safety and management accountability. For electricity, gas, hydrogen, oil and district heating operators, an incident can affect much more than corporate systems: it can disrupt control functions, maintenance activities and the delivery of essential services.

Directive (EU) 2022/2555 expands the entities covered by European cybersecurity requirements and strengthens expectations around risk management, incident reporting and supplier security. Its application depends on the organisation’s classification and the relevant national implementation.

This article explains the requirements in operational terms: which entities may be covered, what management must oversee, how IT and operational technology should be assessed, and what evidence supports a defensible compliance programme.

10 Core NIS2 Risk-Management Requirements

NIS2 requires appropriate and proportionate technical, operational and organisational measures. For energy operators, those measures need to protect both corporate systems and the technology supporting generation, transmission, distribution, storage and other essential services.

The following requirements should translate into clear responsibilities, practical controls and records showing how those controls operate.

1. Risk Analysis and Information Security Policies

Start with the services the organisation must keep operating, then identify the assets and dependencies supporting them. This includes corporate IT, SCADA systems, engineering workstations, communications networks, remote maintenance connections and outsourced services.

A practical cybersecurity risk assessment should describe credible scenarios rather than simply assign scores to individual devices. For example, a compromised engineering account could allow unauthorised configuration changes, while an unavailable identity service could prevent operators from accessing essential applications.

For each priority risk, record the affected service, existing safeguards, treatment decision, responsible owner and review date. Information security policies should reflect those decisions and explain how teams manage access, changes, suppliers and incidents. Review the assessment when new equipment, connections or operating arrangements alter the exposure.

2. Incident Handling

An incident procedure should explain how an alert becomes an operational decision. Security teams need to know who investigates, who assesses service impact, who authorises containment and when operations, legal teams and management must become involved.

A workable NIS2 incident handling and reporting process should connect detection, classification, escalation and evidence preservation. In an energy environment, that means distinguishing an ordinary equipment fault from suspicious activity without delaying investigation when the initial explanation becomes doubtful.

Containment also needs operational judgement. Disconnecting a compromised workstation may be straightforward; isolating a control network could affect visibility or safe operation. Define approval arrangements and suitable response options before an incident occurs.

Retain timestamps, investigation findings, decisions, communications and corrective actions. Exercises should test whether those responsibilities remain clear outside normal working hours.

3. Business Continuity and Crisis Management

Backups are only one part of continuity. Operators also need to understand which services can continue in a degraded mode, which dependencies must be restored first and who authorises a return to normal operation.

For electricity operators, risk management in electrical grids needs to account for telemetry, control signals, communications and coordination between different parts of the network. Restoring an application does not necessarily restore the service if its supporting connections or trusted configuration remain unavailable.

Continuity arrangements should address:

• Recovery priorities for critical systems and services.
• Protected backups of configurations, applications and relevant data.
• Alternative communications and approved degraded operating procedures.
• Dependencies on manufacturers, integrators and replacement equipment.
• Validation before restored systems reconnect to operational networks.

Test realistic restoration scenarios and record the results. Failed tests should produce corrective actions with owners and deadlines.

4. Supply Chain Security

Supplier assessment should focus on what a third party can access, change or interrupt. A maintenance provider with privileged access to industrial equipment presents a different exposure from a supplier that never connects to the operator’s systems.

Define proportionate NIS2 supplier security requirements before contracting and revisit them when the service changes. Relevant requirements may include incident notification, vulnerability coordination, access restrictions, subcontractor visibility and cooperation during recovery.

For critical suppliers, establish:

• Which systems and services depend on them.
• Who can connect and how access is approved.
• What evidence supports their security commitments.
• How unsupported products or delayed fixes are handled.
• How access and support arrangements end when the contract closes.

A completed questionnaire should lead to a decision. Record whether the supplier is accepted, requires remediation or needs additional safeguards, and follow up on unresolved issues.

5. Secure Acquisition, Development and Maintenance

Security should enter the procurement process before equipment or software becomes an operational dependency. Purchasing teams should ask about supported versions, update mechanisms, default accounts, security logging, vulnerability disclosure and the expected support lifecycle.

Where software is developed internally or commissioned from a supplier, practices aligned with the Secure Software Development Framework can help structure development expectations and discussions about software security. The framework supports secure development; it does not replace the organisation’s NIS2 assessment.

Maintenance needs equally clear controls. Changes to firmware, network rules, remote access or industrial configurations should have an owner, an impact assessment, suitable testing and a rollback plan.

If a vulnerability cannot be patched safely within the preferred timeframe, document the reason, interim safeguards and next review date. Technical constraints should lead to a managed treatment decision rather than an indefinite exception.

6. Effectiveness Assessment

A control being installed does not prove that it protects the intended service. Operators should check whether access restrictions work, alerts reach the right people, recovery procedures succeed and supplier accounts expire when expected.

A NIS2 self-assessment can help identify areas needing attention, but operational testing is needed to establish whether important measures work in practice.

Useful checks include sampling access approvals, testing escalation contacts, reviewing configuration changes and verifying that previously identified weaknesses have been corrected. More intrusive technical testing should be coordinated with operations to avoid disrupting industrial systems.

Track outcomes rather than activity alone. “Recovery exercise completed” is less informative than whether the service was restored within its agreed objective and whether critical dependencies were available. Record findings, responsible owners, corrective actions and verification of closure.

7. Cybersecurity Hygiene and Training

Training should reflect the decisions people make in their actual roles. Office staff need to recognise phishing and handle information safely; engineering teams need guidance on removable media, maintenance laptops, supplier access and changes to operational equipment.

Effective NIS2 employee training should also explain how to report suspicious activity and what information to preserve. A technician who notices an unexpected remote session should know whom to contact without needing to decide whether the event is legally reportable.

Management training should cover oversight, service consequences, significant risks and the decisions requiring leadership approval. Contractors should receive relevant instructions before accessing sensitive environments.

Keep records of the content, participants and assessment results. Use incidents, exercises and recurring mistakes to update training, rather than repeating the same presentation regardless of changing exposure.

8. Cryptography

Determine where encryption and other cryptographic protections are appropriate for the organisation’s risks. Relevant areas can include remote maintenance connections, sensitive data transfers, portable devices and backups containing confidential configurations or credentials.

Encryption also depends on effective cryptographic key management. Define who can access keys, how they are protected, when they are replaced and how recovery remains possible if a system or responsible person becomes unavailable.

In operational environments, assess compatibility, performance and reliability before introducing changes. Some legacy equipment may not support the preferred protection directly, requiring an assessment of secure gateways or other compensating measures.

Retain the policy, configuration evidence and documented exceptions. The organisation should be able to explain what is protected, what remains exposed and how that exposure is managed.

9. Personnel, Access and Asset Security

Maintain an inventory that connects important assets to their operational purpose, location, owner and support arrangements. An unidentified engineering workstation or forgotten supplier connection can undermine otherwise well-designed security measures.

Access should follow the user’s responsibilities and change when those responsibilities change. Apply appropriate controls when employees join, move roles or leave, and when contractors begin or finish an intervention.

Practical measures include:

• Individual accounts wherever feasible, particularly for privileged activities.
• Approved access limited to the systems and functions required.
• Time-limited supplier permissions where appropriate.
• Reviews of inactive accounts and excessive privileges.
• Prompt revocation following departure or contract termination.
• Controlled physical access to operational equipment and sensitive areas.

Where shared or embedded accounts cannot be eliminated immediately, document the limitation and introduce suitable safeguards. Keep approval records and review outcomes so access decisions remain traceable.

10. Authentication and Secure Communications

Prioritise strong authentication for remote access, privileged administration and systems whose compromise could affect essential services. Apply MFA or continuous authentication where appropriate, considering both the exposure and the system’s operational constraints.

The approach to operational technology security must accommodate reliability, performance and safety requirements. Where an industrial device cannot support stronger authentication directly, assess whether a controlled gateway can enforce authentication before access reaches that device.

Secure communications also matter during an incident. Establish approved channels for operations, security teams, management and relevant external parties, with alternatives if normal email or collaboration services become unavailable.

Test account recovery, emergency access and communication arrangements. Record exceptions and approvals, and ensure that emergency procedures do not quietly become permanent access routes.

Transposition Status in Spain

On 8 July 2026, the European Commission referred Spain to the Court of Justice over its failure to notify complete NIS2 transposition. Operators should distinguish that confirmed development from any subsequent changes to national legislation.

The practical approach is to identify obligations under the Spanish framework currently applicable to the entity while preparing for NIS2 implementation. Draft provisions concerning authorities, reporting arrangements or penalties should not be presented as final law.

Incident procedures should identify the reporting channels that currently apply, with a defined process for updating them when national arrangements change. The same applies to registration requirements, management responsibilities and supervisory procedures.

Preparation can continue while legal details evolve. Asset inventories, controlled supplier access, tested recovery and documented risk decisions address operational exposures that exist independently of the legislative timetable.

Who Does NIS2 Apply To in the Energy Sector?

Energy is an Annex I sector of high criticality. However, inclusion in Annex I does not automatically make every energy company an essential entity.

As a general rule, medium-sized and larger entities within the listed categories fall within scope. Large Annex I entities are generally essential, while medium-sized entities are generally important. Specific designations and other provisions can bring smaller entities into scope.

The assessment should examine the legal entity, activity, employee and financial thresholds, group relationships and applicable national rules.

Covered categories include:

• Electricity supply undertakings, producers, transmission and distribution system operators.
• Nominated electricity market operators and relevant aggregation, demand-response, storage and recharging-point operators.
• District heating and cooling operators.
• Gas supply, transmission, distribution, storage, LNG and relevant treatment operators.
• Oil pipeline, production, refining, treatment, storage and transmission operators, including central stockholding entities.
• Hydrogen production, storage and transmission operators.

An operator should also distinguish direct obligations from requirements passed down through contracts. An equipment supplier or maintenance contractor may face cybersecurity conditions from an energy customer without being classified in the same way as that customer.

For organisations established in several Member States, the assessment should identify the relevant jurisdiction and reporting arrangements for each entity. ACER’s electricity cybersecurity role supports sector cooperation and the electricity cybersecurity network code, but ACER is not the general NIS2 supervisory authority for every energy operator.

The Core Obligation: Proportionate and Documented Risk Management

NIS2 requires appropriate and proportionate technical, operational and organisational measures. Proportionality considers factors such as exposure, size, implementation costs and the potential impact of an incident.

For energy operators, that means assessing corporate IT and operational technology together. A corporate identity service, remote-support connection or maintenance platform may create an attack path into an operational environment.

The principal areas include:

• Risk analysis and information security policies. Identify critical services, supporting systems, dependencies and risk owners. Review assessments when infrastructure, suppliers or operating conditions change.
• Incident handling. Define detection, classification, containment, recovery and escalation procedures, including how significant incidents are identified.
• Business continuity and crisis management. Prepare backups, recovery arrangements and emergency operating procedures that consider the safe restoration of energy services.
• Supply chain security. Assess suppliers and service providers according to their access, dependencies and ability to affect operations.
• Secure acquisition, development and maintenance. Include security requirements in procurement, integration, configuration and change processes.
• Effectiveness assessment. Test whether measures work and record deficiencies, corrective actions and follow-up decisions.
• Cybersecurity hygiene and training. Give personnel knowledge appropriate to their responsibilities, including operational teams and management.
• Cryptography. Determine where encryption and other cryptographic measures are appropriate, considering industrial compatibility and operational constraints.
• Personnel, access and asset security. Maintain inventories, control privileges and manage access throughout the employment and contractor lifecycle.
• Authentication and secure communications. Apply MFA or continuous authentication where appropriate, alongside suitable secure communication arrangements.

These areas are reflected in ENISA’s NIS2 implementation guidance. That guidance supports specified digital-sector entities; energy operators should adapt useful practices to their own legal scope and operating conditions.

Energy NIS2 Controls and Evidence at a Glance

The evidence should show more than the existence of a control. It should establish which systems it covers, who maintains it and how its effectiveness is checked.

Management Body Responsibility

NIS2 places cybersecurity approval and oversight at management level. Management bodies must understand the measures adopted and the risks those measures address.

Their responsibilities include:

• Approving cybersecurity risk-management measures.
• Overseeing implementation.
• Undertaking appropriate cybersecurity training.
• Addressing accountability under the applicable national framework.

Delegating technical work to a CISO does not remove the need for management oversight. Directors do not need to administer industrial systems, but they need enough information to challenge unresolved exposures and approve resources.

A useful management report should explain service consequences: which assets remain exposed, what could interrupt operations, which remediation decisions are overdue and what risk remains after treatment.

For example, “12 critical vulnerabilities remain open” gives limited context. A stronger report explains whether those vulnerabilities affect remote access to a control environment, what compensating measures exist and when remediation can occur safely.

Decisions should be recorded, including accepted residual risks, funding approvals and follow-up actions. Training and governance responsibilities can be organised using ENISA’s mapping of NIS2 obligations to cybersecurity roles.

Incident Management and Notification

The reporting process applies to incidents meeting the significant-incident criteria. Under NIS2, significance includes severe operational disruption or financial loss, or considerable material or non-material damage to other persons.

The initial deadlines run from awareness of a significant incident, not from completion of the investigation.

If the incident remains ongoing when the final report is due, a progress report is required, followed by a final report within one month of handling the incident. Intermediate updates may also be requested.

The NIS2 incident-reporting framework should be translated into an internal process with named decision-makers, deputies and out-of-hours arrangements. The reporting channel must be confirmed under the applicable national framework.

For energy operators, exercises should test whether the SOC, control room, operations team and legal function can exchange enough information quickly. A loss of telemetry may initially look like a technical fault; the process should establish when that assessment needs reconsideration.

Record the awareness time, classification reasoning, information available and notifications submitted. Incomplete information should be identified as provisional, with follow-up actions assigned.

Digital Supply Chain Security

Supplier risk is particularly important where external parties maintain industrial equipment, support critical applications or access operational environments.

The assessment should cover four main groups:

• OT and SCADA integrators: remote maintenance, engineering access, firmware changes and support credentials.
• Cloud and SaaS providers: platforms supporting maintenance, analytics, asset management or corporate operations.
• Hardware and firmware manufacturers: update dependencies, support availability, replacement options and product lifecycle constraints.
• Subcontractors: parties whose access or work can affect critical systems, including occasional interventions.

A contract is only part of the control. Operators also need to know whether access remains enabled, which subcontractors can connect and how supplier incidents will be communicated.

Classify suppliers by operational significance rather than applying the same questionnaire to everyone. A vendor with privileged access to a control system warrants different scrutiny from a supplier with no access to sensitive environments.

Reviews should produce decisions: restrict access, require stronger authentication, resolve unsupported components or establish alternative support. Where audit rights, exit arrangements or notification commitments are needed, define them according to the service and applicable requirements.

Technical Measures for Energy IT/OT Environments

NIS2 does not prescribe a single industrial architecture. Operators should select measures according to their risks and explain how those measures protect the relevant services.

Practical priorities include:

• Network segmentation between corporate IT and operational environments.
• Approved and documented communication paths.
• Controlled privileged and remote access, particularly for suppliers.
• Monitoring suited to industrial systems and operational constraints.
• Vulnerability management with recorded treatment decisions.
• Protected backups and tested recovery procedures.
• Appropriate encryption for sensitive communications and remote connections.

Measures should be coordinated with operations and safety teams. An intrusive scan, untested patch or authentication change can affect equipment availability, so implementation needs suitable approval and validation.

Where a legacy system cannot support a preferred measure, document the limitation and assess compensating controls. Restricting connectivity, using a monitored access gateway or increasing detection may reduce exposure while a replacement or upgrade is planned.

The wider effort to protect critical infrastructure from cyber attacks should connect these technical decisions with supplier management, employee responsibilities and evidence collection.

What PrivaLex Offers in NIS2 Projects for Energy

PrivaLex supports compliance officers, CISOs, operations management and legal teams in translating NIS2 into practical controls, risk decisions and usable evidence.

Energy-sector preparation needs to connect legal scope with actual IT and OT dependencies. Frameworks such as ISO 27001, IEC 62443 and ENS can support that work where relevant, while their requirements remain distinguishable.

Energy Scope and Entity Classification

We assess the legal entity, energy activities, services, size and group structure against the relevant scope rules. The assessment distinguishes potential essential or important status from obligations received through contracts or other regulatory arrangements.

This is particularly useful for groups combining generation, trading, maintenance and shared technology services. A group-wide cybersecurity programme can support several entities, but it should not obscure which entity holds a particular obligation or must make a notification decision.

IT/OT Risk and Control Assessment

We review governance, architecture and operational evidence, including segmentation, engineering access, identity, vulnerability handling and recovery. Findings are connected to service scenarios and assigned to responsible owners.

The assessment also separates missing measures from controls that exist but are poorly evidenced. If a maintenance-access process operates informally, for example, the work may involve introducing approvals, expiry and records rather than replacing the entire technical arrangement.

Management Governance and Training

We help establish management reporting, approval processes and role-based training. The aim is to give leadership enough information to understand exposure, challenge decisions and oversee implementation.

Reporting should make unresolved risks actionable. A dashboard can identify a delayed treatment decision, the affected service, the person responsible and the management action required. This supports meaningful oversight rather than presenting completion percentages without operational context.

Incident and Notification Exercises

We connect detection with legal assessment, operational escalation and reporting decisions. Exercises can examine ransomware, compromised supplier access, loss of telemetry or disruption affecting several jurisdictions.

Each exercise should produce a record of what worked and what needs correction. Findings might include missing deputies, an unavailable reporting channel or uncertainty about who approves an early warning. These issues should become owned actions with deadlines and verification.

OT Supplier and Remote-Access Controls

We help classify suppliers and review both contractual requirements and the access arrangements used in practice. This can cover authentication, approvals, support accounts, session records, subcontractors and vulnerability coordination.

A practical review follows the access lifecycle from request to closure. It should establish whether permissions are limited to the intervention, whether emergency access is controlled and whether the operator can revoke access promptly when a supplier relationship or risk position changes.

Evidence Mapping and Remediation

We identify the records needed to demonstrate important measures, including access reviews, supplier decisions, recovery tests and corrective actions. The roadmap distinguishes urgent operational exposure from documentation gaps.

When preparing for a NIS2 audit or inspection, evidence should be easy to trace to the relevant system and responsible person. A central index can help locate records held in existing tools without requiring teams to duplicate every document.

Framework Alignment and Continuous Readiness

We map shared controls across relevant security and resilience frameworks, preserving their separate scope and reporting requirements. Changes to national implementation should also trigger reviews of authority, registration and notification arrangements.

Maintaining NIS2 compliance requires a continuing review process. New sites, suppliers, remote connections and industrial assets can change exposure. The programme should incorporate those changes instead of relying on the evidence collected during the initial project.

5 Energy-Sector Scenarios a NIS2 Plan Should Cover

The cybersecurity dependencies of the energy sector include industrial systems, communications and cross-border services. Exercises should reflect those dependencies rather than rely solely on office-IT scenarios.

1. Legacy OT cannot be patched on the normal timetable. Assess exposure, segmentation, permitted access and monitoring. Record the treatment decision and review date instead of treating technical limitations as permanent exemptions.
2. A remote supplier account is compromised. Test identification of the session, revocation, containment and supplier coordination. Confirm whether access to other sites or subcontractors changes the incident scope.
3. Time, telemetry or communications become unreliable. Identify which decisions depend on those inputs. Test how teams detect inconsistent information and switch to approved alternatives or degraded operating modes.
4. An incident affects several entities or countries. Establish who coordinates operations and which entities make legal notification decisions. Test consistent updates while protecting sensitive operational information.
5. Backups exist but safe restoration fails. Consider configurations, dependencies, clean recovery environments, vendor support and reconnection approval. Recovery findings should feed into the risk register and corrective-action plan.

Certifications as a Compliance Lever

Certifications and standards can organise evidence, but they do not replace an entity-specific NIS2 assessment.

ISO/IEC 27001 provides a management-system structure for risk assessment, responsibilities, controls and improvement. Its scope needs to cover the relevant services and dependencies.

For operational technology, IEC 62443 provides industrial cybersecurity references, including risk-based zones and conduits. Select the parts relevant to asset owners, system design, integration and product requirements rather than treating the series as one checklist.

Spain’s National Security Framework, ENS, may apply to relevant systems serving public-sector entities. Having a public-sector customer does not, by itself, establish that every system in an energy company falls within ENS scope.

Implementing Regulation (EU) 2024/2690 establishes requirements for specified digital-infrastructure, digital-provider and ICT-service entities. It is not automatically binding on an organisation solely because it is an energy operator.

Relevant electricity entities should also assess the network code on cybersecurity aspects of cross-border electricity flows, alongside applicable critical-entity resilience requirements.

The practical goal is to reuse suitable controls and evidence while maintaining a separate view of each regime’s obligations.

6 NIS2 Non-Compliance Risks for Energy Operators

The consequences depend on national implementation, classification and the circumstances of the infringement.

1. Essential-entity fines. The Directive requires maximum administrative fines of at least €10 million or 2% of worldwide annual turnover, whichever is higher.
2. Important-entity fines. The corresponding maximum must be at least €7 million or 1.4% of worldwide annual turnover, whichever is higher.
3. Management consequences. Liability and any restrictions on management functions depend on the applicable legal provisions and enforcement conditions.
4. Supervisory intervention. Authorities can require information, corrective measures and other action. Certain measures concerning essential entities are subject to specific conditions and safeguards.
5. Commercial and reputational damage. Weak security or insufficient evidence can affect customer assurance, insurance discussions and contractual relationships.
6. Operational and safety disruption. Uncontrolled access or untested recovery can turn a cyber event into a prolonged loss of operational capability.

The European Commission’s explanation of NIS2 supervision and enforcement distinguishes these mechanisms from the national decisions required to apply them.

Operational preparation should therefore address both the controls themselves and the organisation’s ability to demonstrate their execution.

7 Steps to Prepare Your NIS2 Compliance Plan in Energy

1. Determine Scope and Category

Identify the relevant entities, activities and applicable national rules. Record the classification reasoning and confirm registration, supervisory and reporting arrangements.

2. Assess the Gaps

Compare the current position with the requirements. Include operational evidence and interviews with process owners, not only policy reviews.

3. Prioritise by Service Risk

Focus first on exposures that could materially affect critical services. An ISO 27001 risk treatment plan can help structure actions, owners, resources and residual-risk decisions within a wider management system.

4. Establish Governance

Assign responsibility for IT, OT, suppliers, incidents and evidence. Define which decisions require management approval and how overdue actions are escalated.

5. Organise Documentation and Evidence

Connect each priority measure to a responsible person and verifiable records. When documenting ISO 27001 controls, the same principle applies: distinguish what the procedure requires from evidence that it was performed.

6. Test the Plans

Run incident, notification and recovery exercises that include operations and relevant suppliers. Record decisions, weaknesses and corrective actions rather than only attendance.

7. Maintain the Programme

Review the programme after significant changes, incidents and exercises, alongside scheduled reviews. Track corrective actions through closure and verify that the changes achieved their intended result.

Conclusion

NIS2 readiness in the energy sector depends on connecting legal scope, management oversight and operational cybersecurity. Policies are necessary, but they need to be supported by controlled access, assessed suppliers, tested recovery and records of real decisions.

Operators should prioritise the scenarios that could disrupt their services, particularly where legacy OT, remote maintenance and shared infrastructure create dependencies. They should also keep national implementation and reporting arrangements under review.

PrivaLex helps translate those requirements into a proportionate programme with clear ownership and usable evidence. The objective is not simply to prepare a compliance file, but to maintain controls that support safer operation and a coordinated response when incidents occur.

Frequently Asked Questions (FAQs)