Connecting generation and energy storage assets to the Great Britain (GB) distribution network requires demonstrating compliance with Energy Networks Association (ENA) Engineering Recommendation G99 (EREC G99). Following updates introduced under EREC G99 Issue 1 Amendment 8 (and maintained through Issue 2), network operators require explicit cybersecurity assurance for Power Generating Modules (PGMs) and Battery Energy Storage Systems (BESS) as part of the grid-connection compliance process.

This article provides an in-depth analysis of the cybersecurity evidence requirements governed by EREC G99 clauses 9.1.7, 9.1.8, and 9.1.9. It outlines how asset owners, developers, Engineering, Procurement, and Construction (EPC) contractors, and Original Equipment Manufacturers (OEMs) must construct a defensible Power Generating Module Document (PGMD) Cybersecurity Evidence Pack.

Why PGMD Cybersecurity Evidence Matters

The Power Generating Module Document (PGMD) serves as the primary compliance record submitted by a Generator to a Distribution Network Operator (DNO) or National Energy System Operator (NESO) prior to final operational notification (GON/FON).

Historically focused on electrical, protection, and power quality characteristics, the PGMD now incorporates operational technology (OT) cybersecurity. As DERs, BESS, and automated generation modules proliferate, remote communications and automated control interfaces introduce potential attack vectors into critical energy infrastructure.

From a cybersecurity assurance perspective, the evidence should allow the Generator and DNO to understand how communications, remote management, control interfaces and associated systems have been considered and secured.

What EREC G99 actually requires

Under EREC G99, cybersecurity obligations apply across Type A through Type D generation assets, with elevated compliance verification for Type B, C, and D assets that require formal PGMD submissions.

The Core Regulatory Framework

• Explicit G99 Requirements: Clauses 9.1.7, 9.1.8, and 9.1.9 require generators to explicitly confirm that their modules are designed, physically secured, and documented in accordance with recognized cybersecurity standards and connection guidance.

• Applicable Standards & Guidance: G99 explicitly identifies the following cybersecurity guidance and standards, while also allowing reference to other relevant standards incorporated into the design
  
  

  1. BEIS / ENA DER Cyber Security Connection Guidance (aligned with NCSC CAF principles).

  2. ETSI EN 303 645 (Cyber Security for Consumer/Edge Internet of Things, applicable to edge-connected controllers and smart gateways).

  3. PAS 1879 (Energy management systems and smart energy appliances).

Recognized industrial automation standards such as IEC 62443 (where incorporated into system design). IEC 62443 can be used as a supporting OT/IACS security framework where it has been incorporated into the design or used to provide additional assurance.  

Regulatory Distinction: EREC G99 requires the Generator to declare and demonstrate compliance. While G99 specifies the requirement to submit a Cyber Security Statement and evidence of design alignment, it does not prescribe a single mandatory architecture (such as requiring a specific firewall vendor). Technical solutions may vary provided they satisfy the security principles.

Clauses 9.1.7, 9.1.8 and 9.1.9: Clause-by-Clause Analysis

Clause 9.1.7: Cybersecurity Design Compliance

• Obligation: The Generator must ensure and confirm that the Power Generating Module and associated control/communications equipment are designed to comply with applicable cybersecurity requirements.

• Control Objective: Ensure security by design. Prevent unauthorized network access, unauthenticated control commands, and lateral movement from external or untrusted networks into the OT environment.

• In-Scope Systems: Inverter/Power Conversion System (PCS) controllers, Battery Management Systems (BMS), Plant Controllers (PPC), SCADA gateways, RTUs, and interface firewalls.

• Practical interpretation: Demonstrate that cybersecurity risks have been considered across the PGM's communications, control and management interfaces, including communications with energy management systems and Manufacturer systems used for product management.

Clause 9.1.8: Physical and Site Cybersecurity Boundaries

9.1.8 isn't essentially a cyber evidence obligation.

• Obligation: Ensure physical and logical boundaries protect control systems from unauthorized physical access or local tampering.

• Control Objective: Prevent physical intrusion from translating into logical system compromise (e.g., unauthorized access to local engineering ports, unauthenticated USB devices, or local human-machine interfaces [HMIs]).

• In-Scope Systems: Substation control rooms, BESS enclosure doors, local HMIs, marshalling kiosks, patch panels, and edge gateway enclosures.

Clause 9.1.9: Cyber Security Statement

• Obligation: The Generator shall provide a formal Cyber Security Statement as part of the PGMD submission. This document describes the high-level cybersecurity approach and lists the specific standards and connection guidelines compiled with. The Generator must provide information describing the Power Generating Facility's high-level cybersecurity approach and the specific cybersecurity requirements with which it complies.

• Control Objective: Provide a verifiable, auditable summary that links architecture designs, OEM components, and operational procedures to the governing frameworks (ENA DER Guidance, ETSI EN 303 645, IEC 62443).

• In-Scope Systems: The complete PGM/BESS OT architecture, including third-party vendor interfaces and cloud-connected telemetry links.

Clause-by-clause evidence matrix

The PGMD cybersecurity evidence pack

A defensible PGMD Cybersecurity Evidence Pack should be structured into clear sections:

1. Network & Architecture Evidence

• OT/ICS Architecture Drawing: OT architecture diagram showing logical zones and trust boundaries; a Purdue-style model may be used where appropriate

• Security Zone & Conduit Diagram: Clear delineation of trust boundaries, firewalls, jump boxes, and unidirectionally enforced conduits.

• Remote Access Architecture: Diagram detailing Multi-Factor Authentication (MFA), VPN concentrators, and jump-host architecture for remote vendor maintenance.

2. Device and Hardening Evidence

• Hardware & Software Asset Inventory: Complete asset register including device hardware versions, firmware versions, IP addresses, and MAC addresses.

• Hardening Baselines: Configuration exports demonstrating disabled unused services (e.g., Telnet, HTTP, FTP), closed unused physical ports, and enforced password complexity.

• Malware & Endpoint Protection: Evidence of anti-malware, application whitelisting, or host-based intrusion protection installed on HMIs and Engineering Workstations (EWS).

3. Identity, Access and Log Management

• Account Register: List of system accounts proving removal or renaming of default vendor accounts (admin, root).

• Role-Based Access Control (RBAC): Documented privilege hierarchy for operational staff, maintenance contractors, and OEMs.

• Logging Configuration: Proof that OT network switches, firewalls, and SCADA gateways forward syslogs to a centralized, secure log repository or SIEM.

4. Verification and Testing Evidence

• Factory Acceptance Testing (FAT) Cyber Sign-off: FAT protocols showing cybersecurity test cases passed prior to site delivery.

• Site Acceptance Testing (SAT) / Commissioning Test Records: Commissioning records verifying firewall rules, user access, and port security on the actual deployed asset.

• Penetration Test / Vulnerability Scan Report: Where appropriate to the asset's architecture and risk profile, provide vulnerability assessment or penetration-testing evidence covering externally exposed or security-critical interfaces.

Evidence ownership: OEM vs. EPC vs. Asset Owner

Legend: A = Accountable | R = Responsible | C = Consulted | I = Informed
Illustrative evidence RACI. The Generator retains accountability for the G99 submission, while individual artefacts may be produced by EPCs, integrators and OEMs."

Dealing with Weak OEM Declarations

Asset owners frequently encounter statements like: "Our inverter system complies with international cybersecurity best practices." 

Why this fails: DNO reviewers and auditors cannot verify compliance against high-level assertions.

Remediation Approach:

1. Contractual Requirements: Require suppliers to provide component-level evidence (e.g., IEC 62443-4-2 certification, ETSI EN 303 645 test reports, or hard copy configuration baselines) prior to milestone payments.

2. Objective Evidence Requests: Replace requests for "proof of security" with requests for specific engineering artifacts:

   • System interface specifications detailing all open ports/protocols.

   • Software Bill of Materials (SBOM) or firmware version declarations.

   • Known vulnerability remediation logs (CVE patches applied).

Sample declaration: The above design was independently assessed, configuration verified against the approved baseline, and SAT evidence demonstrates that the implemented configuration corresponds with the submitted architecture.

BESS and generation case examples

Example A: Grid-Scale Battery Energy Storage System (BESS)

• Asset: 50MW / 100MWh Standalone BESS connected at 33kV.

• Cyber Risk: Malicious manipulation of State of Charge (SoC) or thermal management parameters via compromised remote BMS gateway.

• Relevant Control: Segmentation between cloud telemetry gateway, Power Plant Controller (PPC), and local BMS controllers.

• Required Evidence: Dual-firewall architecture documentation, active rule base prohibiting direct cloud-to-BMS traffic, and SAT logs verifying MFA on jump host.

• Responsible Party: EPC Integrator & BESS OEM.

• Verification Method: Network packet capture during SAT demonstrating all BMS communication is contained within local Zone 2 OT networks.

Example B: Solar PV + Storage Hybrid Site

• Asset: 20MW Solar PV with 10MW co-located BESS sharing a single grid connection point.

• Cyber Risk: Lateral movement from a third-party solar inverter monitoring portal into the shared DNO Active Network Management (ANM) RTU.

• Relevant Control: Segmentation and controlled communications between the monitoring environment and grid-control interfaces

• Required Evidence: Interface Control Document (ICD) mapping all cross-boundary communications; firewall rule export showing ingress blocking from Solar portal to ANM RTU.

• Responsible Party: EPC Contractor.

• Verification Method: Penetration testing targeting the solar monitoring network boundary.

Common evidence gaps and failure modes

1. Corporate-Level Compliance Substitution: Submitting corporate ISO 27001 or Cyber Essentials certificates in place of site-specific OT evidence. Remediation: Provide an asset-specific PGMD pack mapping the actual physical and logical site controls.

2. Design vs. Deployed Asymmetry: Submitting high-level design diagrams that do not match the final on-site installation (e.g., additional unmapped 4G cellular modems installed by OEMs for maintenance). Remediation: Perform an pre-commissioning OT audit to baseline all active network interfaces.

3. Flat Network Architectures: Grouping HVAC, fire detection, BMS, inverters, and grid metering into a single unsegmented subnet. Remediation: Implement VLANs and stateful inter-VLAN routing configured on a managed OT switch/firewall.

4. Missing SAT Verification: Relying on factory tests without validating that secure configurations survived field deployment. Remediation: Include explicit cybersecurity line items on the site commissioning sign-off sheet.

Evidence readiness checklist

Use this checklist prior to formal PGMD submission:

[ ] ARCHITECTURE and DESIGN

    [ ] High-level and detailed OT network diagrams provided.

    [ ] Logical boundaries (firewalls, VLANs) clearly demarcated.

    [ ] Remote access path uses MFA and dedicated jump host.

[ ] DEVICE HARDENING and INVENTORY

    [ ] Complete OT asset register (hardware, firmware, IP, MAC).

    [ ] Default passwords changed across all devices, switches, and HMIs.

    [ ] Unused physical network ports disabled; unused logical ports closed.

[ ] GOVERNANCE and STATEMENT

    [ ] Cyber Security Statement completed and signed by authorized engineer.

    [ ] Referenced standards (ENA DER Guidance, ETSI EN 303 645, IEC 62443) explicitly mapped.

    [ ] Third-party vendor access policies documented.

[ ] VERIFICATION and COMMISSIONING

    [ ] SAT cybersecurity test records attached.

    [ ] Vulnerability assessment / pen test summary report included (if applicable).

    [ ] Incident response contact matrix and backup/restore procedure documented.

The 4-Level Evidence Quality Framework

When assembling evidence for G99 verification, classify every document using this hierarchy to ensure defensibility:

Level 4: VERIFICATION EVIDENCE (Highest Quality)

└── Independent pen tests, SAT sign-off logs, live firewall configuration audits.

Level 3: IMPLEMENTATION EVIDENCE

└── Screenshots of applied settings, device asset lists, active user registers. 

Level 2: DOCUMENTARY EVIDENCE

└── Approved architecture drawings, written policies, interface design specs.

Level 1: ASSERTION (Lowest Quality - Unacceptable alone)

└── Self-declarations, generic marketing material, high-level supplier letters.

A defensible PGMD submission relies primarily on Level 3 and Level 4 evidence, supported by Level 2design documentation. Level 1 assertions alone are insufficient for DNO verification.

Practical 30/60/90-Day Preparation Plan

T-90 Days (~90 days before planned submission/commissioning): ARCHITECTURE & SCOPING

 ├── Establish OT security scope across EPC and OEMs.

 ├── Draft site OT Network Architecture and Zone/Conduit maps.

 └── Enforce cybersecurity evidence delivery milestones in OEM procurement contracts.

T-60 Days: HARDENING & EVIDENCE COLLECTION

 ├── Collect component-level evidence (firmware lists, hardening baselines).

 ├── Draft the G99 Cyber Security Statement.

 └── Review remote-access architecture and MFA configurations. 

T-30 Days: TESTING, AUDIT & SUBMISSION

 ├── Execute SAT cybersecurity test scripts on-site.

 ├── Compile Level 3/4 evidence (screenshots, firewall exports, audit logs).

 └── Assemble final PGMD Cybersecurity Evidence Pack for DNO submission.

Where procurement or construction is already underway, the same activities should be run as a compressed evidence-recovery programme.

Understanding the evidence chain requirement

G99 requirement

↓

Cybersecurity requirement / control objective

↓

Site architecture & OEM design

↓

Configured implementation

↓

FAT / SAT verification

↓

Final Cyber Security Statement

↓

PGMD submission

The most defensible submission is not a folder of unrelated certificates. It is an evidence chain showing that the requirement identified in G99 has been translated into a design decision, implemented in the actual asset and verified before commissioning.

Demonstrating cybersecurity compliance for EREC G99 clauses 9.1.7, 9.1.8, and 9.1.9 requires moving beyond corporate policy statements to deliver verified, asset-specific OT technical evidence. By establishing clear evidence ownership early across OEMs and EPCs, enforcing proper network segmentation, and validating deployment during SAT commissioning, asset owners and developers can construct a defensible PGMD package that satisfies DNO grid-connection requirements.

Sources and references

• Energy Networks Association (ENA): Engineering Recommendation G99 (Requirements for the connection of generation equipment in parallel with public distribution networks).

• ENA / BEIS: Distributed Energy Resources – Cyber Security Connection Guidance.

• ETSI: ETSI EN 303 645 (Cyber Security for Consumer Internet of Things: Baseline Requirements).

• BSI: PAS 1879 (Energy management systems and smart energy appliances - Code of practice).

• NCSC: Cyber Assessment Framework (CAF) for Critical National Infrastructure.

Schedule a free briefing on EREC G99 clauses 9.1.7, 9.1.8, and 9.1.9 compliance

Access unique OT security reports

Download free OT security regulatory playbooks

Exclusive OT security E-books for security teams