From EPC Documentation to System Assurance

European BESS projects are still often delivered as though their complexity ends at electrical connection and equipment commissioning. It does not.

Once a storage plant is dispatched through software, connected to market actors, controlled remotely, integrated with TSO or DSO systems, and dependent on cloud, telecom and supplier services, it becomes a cyber-physical system. Its value depends on coordinated digital operation, while its failures may be commercial, operational, cybersecurity-related, regulatory or safety-relevant.

This changes what it means to design and accept the plant. Drawings, equipment schedules and conventional commissioning records remain necessary, but they do not demonstrate that command paths are controlled, interfaces behave correctly, recovery is possible, suppliers can be governed, or the Owner possesses the evidence required to operate the asset throughout its lifecycle.

The applicable legal perimeter varies by country, entity, activity, size, criticality, market role and connection arrangement. Engineering, however, cannot be limited to the minimum obligations that are unquestionably applicable on the day the contract is signed. A BESS expected to operate for fifteen or twenty years must be designed for foreseeable changes in electricity-market rules, cybersecurity obligations, product regulation, data access, battery traceability and critical-infrastructure resilience.

The practical question is therefore not simply whether a particular regulation applies to a particular plant today. It is whether the delivery model can produce a system that remains operable, secure, recoverable, auditable and adaptable as its technical, commercial and regulatory environment evolves.

European utility-scale battery energy storage systems can no longer be delivered as collections of electrical equipment, supplier packages and conventional commissioning documents. Their market-facing, software-dependent and remotely operated nature requires systems engineering, explicit integration ownership, cybersecurity-by-design, controlled interfaces, evidence-based FAT and SAT, demonstrated recovery and continuous lifecycle assurance.

The document-complete but assurance-incomplete plant

Many EPC and Balance of Plant contractors still treat project documentation as a collection of discipline-specific artefacts:

• single-line diagrams;
• protection schemes;
• equipment schedules;
• cable lists;
• rack layouts;
• civil layouts;
• network drawings;
• bills of materials;
• vendor datasheets;
• installation procedures;
• conventional commissioning checklists.

These artefacts are necessary. The error is to equate their existence with a complete design.

A plant may be document-complete but assurance-incomplete. It may have a detailed rack layout without a privileged-access model, a network drawing without a trust model, a firewall in the bill of materials without an approved rule base, a cloud interface without a data-rights model, or a backup appliance without a verified recovery capability.

This approach was sometimes tolerable for earlier photovoltaic and wind projects whose dominant contractual objective was comparatively narrow: construct the plant, connect it, maintain an agreed availability level and produce energy for ten or fifteen years.

A BESS changes the problem. Its value does not arise merely from being electrically available. It arises from being actively and correctly operated in response to:

• market schedules;
• balancing opportunities;
• capacity obligations;
• TSO or DSO instructions;
• state-of-charge constraints;
• battery-health constraints;
• active- and reactive-power requirements;
• network limitations;
• availability declarations;
• trading and optimization decisions.

A BESS is therefore not simply an electrical asset. It is a software-mediated, market-facing cyber-physical system.

Two new requirements change the nature of delivery

BESS projects introduce two requirements that were less dominant in the traditional renewable-plant delivery model.

Active market and system operation

The European electricity-market framework expressly treats storage and flexibility as active parts of the electricity market. Regulation (EU) 2019/943 requires market rules to enable the efficient dispatch of energy storage, while Directive (EU) 2019/944 establishes common rules covering the generation, transmission, distribution, storage and supply of electricity. The 2024 electricity-market reform further reinforced flexibility and storage as instruments for integrating variable renewable generation.¹

This means that the plant must interact with a larger operational ecosystem:

• Owner EMS and trading systems;
• BRP and BSP processes;²
• aggregators;
• market platforms;
• scheduling and nomination functions;
• local SCADA/EMS/PPC;
• TSO and DSO interfaces;
• remote operations centres;
• cloud or vendor services.

Cybersecurity and resilience

The same integration that creates commercial value also enlarges the attack surface. Every additional command source, broker, API, VPN, remote-support session, cloud connector, market interface and telemetry flow adds:

• an identity to govern;
• an interface to authenticate;
• a route to restrict;
• a protocol to classify;
• a failure mode to analyse;
• a log source to preserve;
• a supplier dependency to control;
• a recovery scenario to test.

The first requirement therefore increases pressure on the second. The commercial system and the cybersecurity system are not separate architectures. They are different views of the same plant.

%%{init: {"theme": "neo", "look": "handDrawn", "layout": "elk"}}%%
flowchart TD
    M["More market participation"] --> I["More digital interfaces"]
    I --> V["Higher operational and commercial value"]
    I --> F["More failure and attack paths"]
    F --> C["Stronger command governance"]
    F --> S["Stronger cybersecurity"]
    F --> R["Stronger resilience and recovery"]
    C --> A["System assurance"]
    S --> A
    R --> A
    A --> V

Figure 1: Market integration creates value by increasing connectivity and control, but the same coupling increases the need for cybersecurity and system assurance.

Why traditional EPC artefacts are insufficient

Some examples of gaps where traditional EPC artefacts fall short:

• An electrical drawing answers an electrical question, but it does not automatically answer a system question.
• A single-line diagram can show energy flow. It does not establish command authority.
• A rack layout can show the physical position of servers and switches. It does not establish security zones or management-plane separation.
• A network diagram can show connectivity. It does not prove that communication is default-deny, authenticated, logged, recoverable or restricted to a defined operational purpose.
• A firewall in a bill of materials does not prove:
  • that all inter-zone traffic passes through it;
  • that rules are endpoint-specific;
  • that broad subnet rules are absent;
  • that local routes cannot bypass it;
  • that failover preserves the same policy;
  • that prohibited paths have been tested.
• A jump host does not prove that every remote path uses it.
• A SIEM connector does not prove that the required events are generated, correctly timestamped, buffered, forwarded and retained.
• A backup system does not prove that the plant can be restored within its recovery objectives.
• An IDS sensor does not prove that the critical conduits are visible or that a SPAN failure generates an alarm.

The missing object is the integrated design argument: the traceable demonstration that the plant will satisfy the Owner’s operational, commercial, cybersecurity, resilience and regulatory objectives.

European regulation is converging on demonstrable assurance

No single European regulation tells a BESS developer to use a particular systems-engineering lifecycle, a V-model, SysML or a specific FAT/SAT structure.

The regulations do something more consequential: they impose outcomes that cannot credibly be demonstrated through drawings and equipment lists alone.

Electricity-market integration

The European electricity-market framework requires markets that accommodate storage, flexibility and active participation. The revised rules entered into force in July 2024 and strengthen the role of flexible resources required to complement variable renewable generation.³

This is the regulatory reason why market-facing interfaces, schedules, command ownership, data exchange and operational responsibilities must be treated as first-class design objects.

NIS2

NIS2 establishes a common cybersecurity framework for critical sectors, including energy. It covers governance, risk management, incident handling, business continuity, supply-chain security, vulnerability handling, cryptography, access control and reporting.⁴

NIS2 does not automatically regulate every standalone BESS. Where it applies to the Owner, operator, aggregator, energy undertaking or service provider, however, the plant and its suppliers become part of the entity’s risk-management and supply-chain obligations.

This has a direct procurement consequence: the Owner must be able to obtain evidence from the EPC, BoP, OEM, cloud provider and remote-service provider.

The electricity-sector Network Code on Cybersecurity

Commission Delegated Regulation (EU) 2024/1366 establishes a binding network code on sector-specific cybersecurity rules for cross-border electricity flows. It addresses risk assessment, common minimum requirements, monitoring, reporting, crisis management and supply-chain aspects within the European electricity system.⁵

The Network Code is narrower than NIS2, but more electricity-specific. Its practical significance is that TSO, DSO and other regulated counterparties will increasingly impose structured cybersecurity requirements on connected entities and their interfaces.

A plant may experience this obligation indirectly through:

• grid-code requirements;
• connection agreements;
• TSO or DSO technical specifications;
• telecontrol requirements;
• incident coordination;
• interface testing;
• supplier-security clauses.

The Critical Entities Resilience Directive

Directive (EU) 2022/2557 addresses the resilience of critical entities against all hazards, not only cyber threats. It covers disruption caused by natural events, accidents, physical attacks, insider threats and other hazards affecting essential services.⁶

This matters because BESS resilience cannot be reduced to network security. The integrated design must consider:

• fire;
• flooding;
• loss of auxiliary power;
• physical intrusion;
• theft and sabotage;
• telecom failure;
• loss of cooling;
• supply-chain interruption;
• unavailability of qualified personnel;
• combined physical and cyber incidents.

NIS2 and CER therefore reinforce each other: one emphasizes cyber risk, while the other demands broader operational and physical resilience.

The Cyber Resilience Act

The Cyber Resilience Act applies principally to manufacturers, importers and distributors of products with digital elements rather than directly to ordinary plant operators. Its effect nevertheless propagates into BESS procurement because BESS plants contain products with digital elements: controllers, gateways, applications, firewalls, switches, embedded devices, management software and remote interfaces.

The CRA entered into force in December 2024. Reporting obligations for actively exploited vulnerabilities and severe security incidents affecting products with digital elements apply from 11 September 2026, while the main product obligations apply from December 2027.⁷

The procurement implication is immediate. Owners should already require:

• secure-development evidence;
• vulnerability-disclosure processes;
• security-update commitments;
• support-period declarations;
• software and firmware inventories;
• SBOM availability where relevant;
• notification obligations;
• end-of-support planning.

A plant designed in 2026 may contain equipment placed on the market and supported under the CRA during its operational life.

The Data Act

The Data Act has applied since 12 September 2025. It establishes rules on access to and use of data, including data generated by connected products and related services, and addresses switching between data-processing services.⁸

Its relevance to BESS lies in the allocation and technical enablement of data rights.

A BESS contract should define:

• who may access raw BMS, PCS, EMS and SCADA data;
• whether the Owner can extract data without vendor assistance;
• whether derived data and analytics outputs are included;
• whether APIs are documented and usable;
• how data is retained and deleted;
• whether a vendor can restrict internal Owner processing;
• how cloud switching and service termination are handled;
• how data continuity is preserved if a supplier relationship ends.

Data ownership without technical export capability is not effective control.

The Batteries Regulation and the digital battery passport

Regulation (EU) 2023/1542 introduces lifecycle, sustainability, performance, durability and information obligations for batteries. From 18 February 2027, each light means of transport battery, each electric-vehicle battery and each industrial battery with a capacity greater than 2 kWh placed on the EU market or put into service must have an electronic battery passport.⁹

Utility-scale BESS batteries therefore fall within the passport scope as industrial batteries above 2 kWh. The obligation does not, however, automatically attach to the complete BESS plant as a single asset or separately to every cell and module. It applies to the qualifying finished battery placed on the market or put into service.

The project must consequently identify:

• the battery product or assembly to which each passport applies;
• the economic operator responsible for creating and maintaining it;
• the relationship between the passport identifier and the plant asset hierarchy;
• the relevant container, rack, pack, module and serial-number mappings;
• the systems from which lifecycle and performance data are obtained.

The passport must be accessible through a QR code linked to a unique identifier. It contains both battery-model information and data specific to the individual battery, including applicable information resulting from its use. Access is differentiated: some information is public, while other data is available only to authorities, notified bodies or parties having a legitimate interest under the Regulation.

The battery passport is therefore not merely a PDF linked to a QR code. Its information must use open standards and be available in an interoperable, machine-readable, structured and searchable form. The responsible economic operator must ensure that the information is accurate, complete and up to date.

For a BESS project, the procurement and design package should define:

• the passport-bearing battery unit and unique identifier;
• the responsible economic operator and any authorized passport service provider;
• mandatory model-level and individual-battery attributes;
• sources of performance, durability and state-of-health information;
• interfaces among the passport, BMS, asset register and lifecycle-management systems;
• access rights for the Owner, operator, maintainer, second-life operator and recycler;
• data-quality, integrity, authentication and update responsibilities;
• continuity of passport availability if the manufacturer or service provider ceases activity;
• repurposing, remanufacturing and end-of-life procedures.

The battery passport does not replace the plant asset inventory, configuration baseline, operational historian, cybersecurity log repository or Owner data platform. Nor does the Regulation require all raw BMS telemetry or operational plant data to be published through the passport. The project should instead maintain a controlled mapping between regulated passport attributes and their authoritative plant data sources.

If a battery is repurposed or remanufactured, a new passport must be created and linked to the passport or passports of the original battery. This requirement strengthens the case for structured asset identification, lifecycle data governance and supplier-independent access to battery information.

The AI Act, where AI becomes a safety component

The AI Act does not automatically classify AI-based trading or market optimization as high risk. The classification becomes relevant where an AI system is intended to be used as a safety component in the management or operation of critical infrastructure for the supply of electricity, subject to the intended-purpose analysis and the classification conditions established by Article 6 and Annex III of Regulation (EU) 2024/1689.¹⁰

If AI or machine-learning functionality affects safety-relevant or resilience-relevant BESS decisions, the design should explicitly address:

• intended purpose;
• operational boundaries;
• human oversight;
• accuracy and robustness;
• fallback behaviour;
• model and data governance;
• logging;
• change control;
• cybersecurity;
• validation under abnormal conditions.

The correct engineering rule is not to label every optimizer high risk. It is to determine whether its failure can affect safety, critical infrastructure integrity or continuity, and document that classification.

Regulatory instruments and engineering consequences

Instrument	Primary regulatory concern	Practical BESS design consequence
EU electricity-market framework	Storage participation, flexibility, dispatch and market integration	Market, Owner, EMS, aggregator and TSO/DSO interfaces must be formally designed and tested
NIS2	Cyber-risk management, governance, supply chain, incidents and continuity	Cybersecurity requirements must flow into EPC, BoP, OEM and service-provider contracts
Network Code on Cybersecurity	Electricity-sector cyber risk, minimum requirements, monitoring and crisis management	TSO/DSO conduits and evidence must be treated as regulated interfaces
CER Directive	All-hazards resilience of critical entities	Physical, environmental, telecom, staffing and cyber scenarios must be analysed together
Cyber Resilience Act	Secure products with digital elements and vulnerability handling	Product support, updates, SBOM, disclosure and end-of-support must enter procurement
Data Act	Access to connected-product data and cloud-service switching	Owner data access, APIs, export, deletion and exit must be technically enforceable
Batteries Regulation	Battery lifecycle information, performance, sustainability and passport	Asset identity and operational data must remain traceable across the lifecycle
AI Act, conditionally	AI systems used as safety components in qualifying critical-infrastructure use cases	Intended purpose, classification, human oversight, validation, robustness and fallback must be explicitly assessed

Different countries, the same engineering direction

Italy: ACN, NIS2 and an evolving Terna Code

Italy transposed NIS2 through Legislative Decree 138/2024, in force since 16 October 2024. For entities in scope, significant incidents require an early warning within 24 hours, notification within 72 hours and a final report within one month.¹¹

The Perimetro di Sicurezza Nazionale Cibernetica remains relevant to specifically designated entities and assets; it should not be presented as a general obligation applying automatically to every Italian BESS.¹²

For a BESS connected to the Italian transmission network, or otherwise subject to the relevant Terna connection, telecontrol, defence-system or dispatching requirements, the plant also operates within an evolving Terna framework. Depending on the connection configuration and services provided, Terna’s Grid Code may include:

• Annex A.13 on connection to Terna’s control system;
• Annex A.69 on connection to the defence system;
• Annex A.79 on electrochemical storage systems;
• dispatching rules and command-message requirements.

Terna published updated Grid Code documents, including a revised Annex A.13, on 14 May 2026.¹³

The Italian lesson is that operational integration and cybersecurity cannot be separated. Telecontrol, dispatch orders, plant command paths, data availability and cybersecurity evidence must be designed as one system.

Germany: NIS2, energy IT security catalogues and digital energy services

Germany’s NIS2 Implementation Act entered into force on 6 December 2025.¹⁴

The Bundesnetzagentur maintains sector-specific IT security catalogues for electricity and gas networks and for energy installations. Pending publication of revised catalogues, the existing catalogues remain applicable to their existing addressees, and existing attack-detection systems must continue to operate.¹⁵

Germany is also developing an IT security catalogue for operators of digital energy services, a category regulated by Bundesnetzagentur since December 2025. Consultation is planned for August 2026.¹⁶

This is particularly relevant to BESS because plant operation may depend on entities that are neither the physical asset owner nor the original EPC contractor:

• aggregators;
• dispatch optimizers;
• third-party operating centres;
• cloud EMS providers;
• flexibility-service providers;
• remote data platforms.

The German direction therefore extends assurance beyond the physical installation and into the digital operating service.

France: existing OIV discipline and an unfinished NIS2 transition

France had not completed NIS2 transposition by 8 July 2026, when the European Commission referred France and several other Member States to the Court of Justice.¹⁷

That delay does not imply the absence of a security framework. France already has an established regime for operators of vital importance and information systems of vital importance. Existing rules include incident-management and cyber-crisis procedures.¹⁸

ANSSI also published ReCyF version 2.5 in March 2026 as a working cybersecurity reference designed to support future essential and important entities in meeting NIS2 objectives.¹⁹

The French lesson is important: project engineering should not wait for the final legislative text. A plant being designed today should already incorporate the security outcomes that are technically foreseeable.

The Netherlands: cyber and critical-entity resilience entering together

On 7 July 2026, the Dutch Parliament approved the Cyberbeveiligingswet and the Wet weerbaarheid kritieke entiteiten. Both laws will enter into force on 15 August 2026.²⁰ The two laws implement the cyber and physical-resilience sides of the European framework together.

This reinforces a systems-level view of BESS resilience. For a relevant entity, it is not sufficient to secure the firewall while leaving unanalysed:

• physical perimeter failure;
• cooling failure;
• telecom dependence;
• loss of external services;
• loss of maintenance personnel;
• supplier insolvency;
• prolonged grid disturbance;
• combined physical and cyber attack.

Belgium: operational NIS2 and contractual supply-chain pressure

Belgium implemented NIS2 through its law of 26 April 2024, effective from 18 October 2024. Belgium was the first Member State to announce full implementation.²¹

Belgian guidance emphasizes supply-chain security. A supplier may face cybersecurity requirements even if it is not independently within NIS2 scope, because a regulated entity must manage the cybersecurity of direct suppliers and service providers.²² By 18 April 2026, Belgian essential entities had to be able to demonstrate implementation of risk-management measures through a recognized compliance pathway.²³

This is a practical model for BESS procurement: regulatory responsibility remains with the regulated entity, but the evidence must be produced across the supply chain.

Great Britain: outcome-based assurance through NIS and the CAF

Great Britain remains outside the EU framework but provides a useful comparator. The Network and Information Systems Regulations 2018 require operators of essential services to take appropriate and proportionate measures to manage risk, prevent and minimize incidents, and protect service continuity. Ofgem issued updated guidance for downstream gas and electricity operators in January 2026.²⁴

The NCSC Cyber Assessment Framework is explicitly designed to help essential-service organizations assess and demonstrate cyber resilience.²⁵ The UK government also published an updated Energy Sector Cyber Security Strategy in May 2026, emphasizing risk understanding, supply-chain security and the resilience of a clean and increasingly digital energy system.²⁶

The UK example demonstrates the same methodological shift: regulation is moving from product checklists toward evidence that essential outcomes are being achieved.

From EPC delivery to system assurance

The regulatory outcomes and operational demands described above expose the central weakness of the conventional EPC model. The problem is not the quality of its electrical, civil or mechanical engineering. It is the absence of a discipline responsible for demonstrating that all supplied subsystems will operate together as the Owner requires.

Systems engineering supplies that missing discipline. It connects Owner objectives and regulatory outcomes to plant functions, accountable parties, interfaces, controlled configurations, verification activities and retained acceptance evidence.

The integration gap in conventional EPC delivery

A traditional EPC process tends to decompose the plant by engineering discipline, supplier package and contractual scope. One supplier may design the battery system, another the PCS, another the EMS or PPC, another the SCADA, another the telecommunications infrastructure, while the BoP contractor connects the resulting equipment. Additional parties may provide:

• grid-interface and telecontrol systems;
• protection and measurement equipment;
• remote-service platforms;
• cloud analytics;
• Owner data platforms;
• market and optimization systems;
• cybersecurity products;
• backup and recovery services;
• SOC or NOC monitoring;
• telecom links and time synchronization.

Each party may deliver drawings, datasheets, test certificates and interface information for its own scope. The project can therefore appear complete even though no party has demonstrated the fitness of the integrated plant. This is particularly dangerous for BESS projects because the plant’s expected behaviour emerges from interactions among:

• electrical equipment;
• embedded controllers;
• BMS and PCS logic;
• EMS, PPC and SCADA applications;
• grid-interface and telecontrol systems;
• market schedules and dispatching instructions;
• operators and maintenance personnel;
• Owner, aggregator and trading platforms;
• remote services and cloud systems;
• telecommunications and time synchronization;
• cybersecurity, logging and recovery controls.

A battery container can operate correctly in isolation, a PCS can comply with its own specification, an EMS can calculate valid setpoints and a firewall can enforce its configured policies, while the complete plant still fails to satisfy the Owner’s operational objective. The integration failure may concern:

• command precedence;
• state-of-charge constraints;
• timing and synchronization;
• conflicting operating modes;
• grid-code behaviour;
• degraded operation;
• remote-access governance;
• logging and forensic evidence;
• backup and recovery;
• market-interface semantics;
• responsibility allocation among suppliers.

A collection of individually compliant components does not automatically produce a compliant, secure or operationally fit system.

From equipment delivery to system behaviour

The distinction between the conventional approach and the required delivery model can be summarized as follows:

Dimension	Conventional EPC approach	System-assurance approach
Starting point	Equipment scope and discipline drawings	Owner objectives and intended operational use
Primary design unit	Individual equipment or supplier package	Integrated system and end-to-end behaviour
Requirements	Distributed across contracts, drawings and supplier documents	Consolidated, testable and traceable requirements baseline
Interfaces	Connections documented between packages	Controlled agreements with defined semantics, responsibilities and failure behaviour
Command authority	Often inferred from connectivity or product functionality	Explicitly allocated, mediated, constrained and tested
Cybersecurity	Products and controls added to the network design	Trust boundaries, command paths and conduits designed together with plant functions
Integration	Completed mainly during commissioning	Planned and verified progressively throughout the project
Testing	Demonstration that equipment and signals work	Verification of requirements and validation of operational fitness
Negative testing	Limited or absent	Demonstration that unauthorized, unsafe or unintended behaviour is prevented
Acceptance	Completion of documents and successful test procedures	Traceable evidence that Owner objectives and requirements are satisfied
Lifecycle	Focus on construction and initial handover	Design, operation, maintenance, update, recovery and retirement considered together

The better delivery model is systems engineering: a disciplined process for converting stakeholder objectives into requirements, allocating those requirements to systems and accountable parties, controlling interfaces, integrating subsystems, and producing objective evidence that the completed plant is fit for its intended use.

This does not require the wholesale adoption of an aerospace, maritime or software-development framework. ISO/IEC/IEEE 15288, the NASA Systems Engineering Handbook, maritime system-integration methodologies and the V-model are relevant because they contain established techniques for controlling integration risk in complex systems.²⁷

Their terminology may differ, but their common principles are directly applicable to BESS delivery:

1. define the intended operational use before freezing the technical solution;
2. convert Owner objectives into clear and testable requirements;
3. allocate every requirement to a system and an accountable party;
4. specify every material interface before implementation;
5. control implementation against an approved configuration baseline;
6. verify that the implementation conforms to its requirements;
7. validate that the integrated plant performs correctly in its real operating environment;
8. retain the evidence necessary to support acceptance, operation, audit and incident investigation.

The purpose is not to make a BESS project resemble an aerospace programme or shipbuilding project in every procedural detail. The purpose is to apply the same fundamental discipline used in other complex systems: design the integrated behaviour before installation, assign responsibility for every material interface, and verify the completed system against the Owner’s intended use.

Verification and validation are not the same

The distinction between verification and validation is fundamental.

Verification asks whether the system has been implemented according to its specification. A communication test may verify that:

• an EMS can send a setpoint;
• a controller receives it;
• the value is written to the expected register;
• the receiving device acknowledges it.

Validation asks whether the resulting arrangement satisfies the Owner’s intended operational need. For the same dispatch process, validation must establish that:

• only an authorized party can initiate the instruction;
• the instruction enters through the approved command path;
• the EMS or PPC validates it before execution;
• the value is checked against plant and battery constraints;
• competing command sources are correctly prioritized;
• stale, duplicated, malformed or out-of-range instructions are rejected;
• the action and its result are logged;
• the resulting plant response is observable;
• a communication failure produces a defined operational state;
• the process remains safe and traceable under degraded conditions.

A technically successful signal exchange may therefore pass verification while the complete operating process fails validation.

Experience from other complex sectors is relevant because they face the same structural problem. Ships and offshore units combine automation, propulsion, navigation, safety, communication and power systems supplied by multiple organizations. Aerospace programmes combine hardware, software, operators, facilities and external services under strict interface and evidence controls. Large software platforms use progressive component, integration, system and acceptance testing because successful modules do not guarantee a successful system. The transferable lesson is that subsystem conformity does not demonstrate integrated-system fitness.

Cybersecurity must be integrated into the system model

IEC 62443 provides a complementary structure for the cybersecurity dimension. Its risk-based zone-and-conduit model helps divide an industrial control system into trust domains and explicitly controlled communication paths.²⁸

This is particularly important in a BESS, where different interfaces may carry:

• telemetry;
• operational commands;
• engineering actions;
• administrative access;
• log forwarding;
• backup traffic;
• time synchronization;
• remote-service communication;
• Owner or market-platform integration;
• TSO or DSO telecontrol traffic.

These flows may share physical or virtual infrastructure, but they do not have the same purpose, authority or risk.

Network reachability must not imply:

• command authority;
• engineering authority;
• administrative authority;
• unrestricted data access;
• permission to bypass the EMS or PPC;
• permission to reach field devices directly.

IEC 62443 does not, by itself, define the whole plant delivery model. It does not determine:

• the commercial operating model;
• BRP, BSP or aggregator responsibilities;
• command precedence;
• grid-code behaviour;
• market-interface semantics;
• recovery priorities;
• contractual interfaces;
• Owner acceptance criteria.

These elements must be integrated into the broader functional and operational architecture. A certified component, firewall, jump host, IDS platform or secure-development process does not establish plant security by itself. Its actual role, configuration, interfaces, dependencies and failure behaviour must be designed and tested within the complete system.

Cybersecurity products are implementation elements. They are not substitutes for cybersecurity architecture.

Integration must have an accountable owner

System integration cannot remain an unowned space between the EPC contractor, BoP contractor, battery OEM, PCS supplier, EMS/PPC supplier, SCADA integrator, telecommunications provider, cybersecurity supplier, market operator and remote-service provider.

One party must be explicitly accountable for the integrated-system baseline. Depending on the procurement model, this responsibility may be assigned to:

• the EPC or BoP contractor acting as system integrator;
• a separately appointed system integrator;
• the Owner’s engineering organization;
• another party formally assigned the authority and responsibility to govern integration.

The accountable integrator should maintain, at minimum:

• the system requirements baseline;
• the functional and cybersecurity architecture;
• the interface-control register;
• the command-authority model;
• the responsibility-allocation matrix;
• the configuration baseline;
• the verification and validation plan;
• the FAT/SAT traceability matrix;
• the defect, deviation and residual-risk register;
• the acceptance-evidence package.

Subsystem suppliers remain responsible for their respective products and deliverables, but subsystem conformity does not relieve the system integrator of responsibility for end-to-end behaviour.

The integration role must include both accountability and authority. A party cannot reasonably be held responsible for the complete plant if it lacks the contractual right to:

• obtain supplier information;
• define interface requirements;
• approve configurations;
• require test evidence;
• control changes;
• reject non-conforming implementations;
• require corrective actions;
• escalate unresolved residual risks.

Where no party owns this role, integration is effectively deferred to commissioning personnel working under schedule pressure. That is not integration management; it is late-stage defect discovery.

The assurance chain

The practical objective is not framework compliance for its own sake. It is an unbroken assurance chain connecting the reason the plant is being built to the evidence by which it is accepted.

%%{init: {"theme": "neo", "look": "handDrawn", "layout": "elk"}}%%
flowchart TD
    O["Owner objectives"] --> U["Operational and market scenarios"]
    U --> R["System and cybersecurity requirements"]
    R --> A["Functional, control and cybersecurity architecture"]
    A --> I["Interfaces, zones, conduits and responsibilities"]
    I --> C["Controlled configuration baseline"]
    C --> T["FAT, SAT and operational validation"]
    T --> E["Acceptance evidence"]
    E --> H["Operational handover"]
    H --> L["Lifecycle assurance"]

    T --> D["Defects, deviations and residual risks"]
    D --> R
    D --> A
    D --> C

Figure 2: The system-assurance chain connecting Owner objectives to implementation, acceptance and lifecycle evidence.

Traceability must be bidirectional: the project must be able to move forward from an Owner objective to its implementation and acceptance evidence, and it must also be able to move backwards from a test result, configuration item, interface, defect or operational event to the requirement and design decision that justify it.

The feedback path is essential. A failed FAT or SAT test is not merely a commissioning issue to be closed locally. It may reveal:

• an incorrectly stated requirement;
• an incomplete operational scenario;
• an unallocated responsibility;
• an architectural weakness;
• an interface ambiguity;
• a configuration error;
• an undocumented product limitation;
• an unacceptable residual risk.

The corrective action must return to the appropriate point in the assurance chain. Changing only the test procedure, while leaving the requirement, architecture or configuration unchanged, does not resolve a design defect. Similarly, accepting a temporary workaround without recording its design impact, cybersecurity implications, owner, expiry condition and residual risk merely transfers the problem into operation.

What traceability means in practice

Consider the following Owner objective:

The plant shall support remote dispatch without giving external systems direct access to field devices.

In a conventional project, this requirement may produce a network connection, a VPN and a successful setpoint test. That demonstrates connectivity, but not necessarily safe and controlled dispatch. Under a system-assurance model, the same objective is progressively transformed into:

1. an operational use case defining the authorized dispatching parties, operating conditions and expected plant response;
2. a command-authority requirement defining who may issue instructions and which plant function may accept them;
3. an architectural rule requiring external commands to terminate at the designated EMS/PPC command-governance function;
4. a dedicated and authenticated command conduit separated from telemetry, engineering and administrative traffic;
5. an interface specification defining the command payload, initiator, destination, timing, authentication, acknowledgement and failure behaviour;
6. firewall and application allow-listing restricted to approved sources, destinations and command types;
7. validation controls for authorization, value limits, state of charge, plant availability, timestamps, duplicate instructions and replay attempts;
8. logging capable of reconstructing the command source, validation result, execution result and resulting plant response;
9. FAT tests demonstrating valid-command execution and rejection of unauthorized, stale, malformed or out-of-range instructions;
10. SAT tests demonstrating the complete end-to-end behaviour in the as-built plant;
11. retained evidence linking the test results to the approved requirement, architecture and configuration baseline.

The same traceability must demonstrate the negative architectural property: the external platform cannot directly reach PLCs, PCS controllers, BMS interfaces or other field devices. Without this chain, the project has only an architectural assertion. With it, the project has a reproducible assurance argument showing:

• why the design exists;
• where the requirement is implemented;
• who is responsible;
• how the implementation was tested;
• what evidence supports acceptance.

The five questions every material requirement must answer

For every material requirement, the project should be able to answer five questions.

1. Why is it required? The source may be an Owner objective, regulation, grid code, contract, risk assessment or operational need.
2. Where is it implemented? The requirement must be allocated to a system, subsystem, interface, configuration or operating procedure.
3. Who is responsible? Responsibility must be assigned to the Owner, EPC contractor, BoP contractor, OEM, system integrator, operator or service provider.
4. How will it be demonstrated? The project must define an inspection, analysis, demonstration or test, together with an objective expected result.
5. What evidence will be retained? Acceptance must rely on controlled records, configuration exports, logs, test results, drawings, certificates or other reproducible evidence.

A practical traceability record should therefore contain at least:

Field	Required content
Source	Owner objective, regulation, grid code, contract, risk assessment or standard
Applicability	Reason the requirement applies to the plant, entity, product, interface or service
Requirement	Clear and testable project-level statement
Responsible party	Party accountable for design, implementation and evidence
Design allocation	System, function, interface, zone, conduit or procedure implementing the requirement
Configuration baseline	Relevant software, firmware, parameter, rule or physical configuration
Verification method	Inspection, analysis, demonstration or test
Verification phase	Design review, FAT, SAT or operational validation
Expected result	Objective pass/fail criterion
Evidence	Controlled test record, configuration export, log, drawing or certificate
Deviation status	Open defect, approved deviation, compensating control or accepted residual risk
Acceptance authority	Party authorized to approve the result
Lifecycle treatment	Review, update, retention, support and end-of-life requirements

The assurance process must be contractually established

The project-specific method should be formalized through a System Assurance Plan, Systems Engineering Management Plan, Integration and Verification Plan, or an equivalent controlled project document.

Its title is secondary. Its purpose is to ensure that no requirement, interface, responsibility, security control or operational objective remains disconnected from implementation and testing.

The plan should define:

• the system boundary and integration scope;
• applicable regulatory, grid-code, contractual and Owner requirements;
• the accountable system integrator;
• supplier responsibilities and information obligations;
• lifecycle stages and approval gates;
• required design and assurance artefacts;
• requirements-management rules;
• interface-control rules;
• configuration-baseline and change-control rules;
• cybersecurity architecture and verification methods;
• FAT and SAT structure;
• operational-validation requirements;
• evidence format, ownership and retention;
• defect, deviation and residual-risk treatment;
• operational handover and lifecycle-assurance obligations.

This plan is the bridge between external references and enforceable project delivery:

• Regulations define outcomes.
• Standards and engineering guidance provide methods.
• The contract determines which requirements, artefacts, tests and evidence the Supplier must deliver.
• FAT, SAT and operational validation demonstrate whether the integrated plant has satisfied the Owner’s requirements.

Without this contractual bridge, systems engineering remains an advisory concept. With it, integration discipline becomes part of design approval, Supplier performance and plant acceptance.

Preventing under-engineering and methodology theatre

This delivery model prevents two recurring project failures. The first is under-engineering: regulations and Owner requirements are cited, but they are never converted into system behaviour, interface specifications, configuration rules and acceptance tests.

The project may list NIS2, IEC 62443, grid-code requirements or cybersecurity objectives without identifying:

• the affected assets;
• the responsible party;
• the implementing control;
• the expected configuration;
• the verification method;
• the acceptance evidence.

The second failure is methodology theatre: the project produces architecture diagrams, standards references, certificates and test plans without maintaining real traceability between requirements, implementation and evidence.

Typical examples include:

• a zone diagram that is not reflected in routing and firewall rules;
• a component certificate presented as evidence of system-level security;
• a FAT procedure not linked to an approved requirement;
• a backup product without a restore test;
• a jump host without proof that all remote paths use it;
• an IDS without evidence that critical conduits are monitored;
• a command interface without negative testing of bypass paths;
• a configuration baseline that is not compared with the as-built plant.

A stronger design process prevents both failures by making integration an explicit project responsibility:

• Interfaces are designed before site commissioning.
• Command authority is established before external platforms are connected.
• Cybersecurity zones and conduits are defined before firewall rules are configured.
• Recovery objectives are defined before backup products are selected.
• Logging requirements are defined before SIEM connectors are installed.
• FAT and SAT procedures are derived from requirements rather than assembled after installation.
• Commissioning should verify the architecture, not invent it.

A better way to build BESS plants

System assurance does not replace conventional engineering documentation. It gives that documentation a coherent purpose. Electrical schemes, civil layouts, rack layouts, cable schedules, equipment specifications, network diagrams and bills of materials remain necessary. They become reliable project evidence only when they are connected to:

• Owner objectives;
• operational scenarios;
• system requirements;
• integrated architecture;
• responsible parties;
• controlled interfaces;
• approved configurations;
• verification and validation;
• retained evidence.

The difference is not between documentation and no documentation. It is between an uncoordinated set of discipline artefacts and a traceable body of evidence supporting the fitness of the complete plant. The result is not merely a collection of installed components. It is a plant whose integrated behaviour has been:

• defined before construction;
• allocated to accountable parties;
• implemented against a controlled baseline;
• verified during development and integration;
• validated in its operating environment;
• evidenced for acceptance;
• prepared for operation, maintenance, recovery and change.

That is the practical evolution required for European BESS delivery: from equipment-centred EPC documentation to evidence-based system assurance.

What the stronger design phase must produce

The system-assurance model becomes effective only when it produces concrete, controlled and testable design artefacts. These artefacts are not independent documents prepared by different suppliers and assembled at the end of the project. They form a connected design baseline. Each one should identify:

• its accountable owner;
• its inputs and source requirements;
• the systems and interfaces within scope;
• its approval status;
• the downstream configurations and tests derived from it;
• the conditions under which it must be updated.

The stronger design phase should produce, at minimum, the following artefacts:

Design artefact	Principal question answered	Primary project use
Concept of Operations	How will the plant actually be operated?	Defines intended use, actors, operating modes and operational authority
Requirements baseline	What must the complete plant achieve?	Converts objectives and obligations into testable statements
Functional architecture	Which functions are required and where are they allocated?	Separates system behaviour from individual products
Interface-control model	How do systems exchange data, commands and services?	Prevents ambiguous or undocumented integration
Command-authority model	Who may influence plant behaviour, through which path and under which controls?	Prevents conflicting, bypassed or unauthorized control
Cybersecurity architecture	How are trust, access, conduits and security services structured?	Converts cybersecurity objectives into enforceable architecture
Recovery model	How will plant functions and evidence be restored after failure or compromise?	Derives backup, restoration and degraded-mode requirements from operational objectives

These artefacts should be approved before detailed configuration is frozen. FAT and SAT procedures should be derived from them, rather than written independently after equipment has already been installed.

Concept of Operations

The Concept of Operations, or ConOps, defines how the complete plant is intended to work from the perspective of the Owner, operators, market participants, grid operators, maintainers and external service providers.

It should describe normal operation, exceptional operation and degraded operation before the technical solution is finalized. At minimum, it should define the following:

1. Operating actors and organizational roles. Identify the parties that participate in plant operation, including:

   • Owner;
   • plant operator;
   • control-room operator;
   • trader;
   • Balance Responsible Party;
   • Balancing Service Provider;
   • aggregator;
   • TSO or DSO;
   • EMS/PPC operator;
   • maintenance provider;
   • battery and PCS OEMs;
   • remote SOC/NOC;
   • cloud or analytics provider.

   For each actor, define whether it may monitor, request, approve, command, configure, maintain or investigate the plant.

2. Monitoring and alarm responsibility. Define:

   • who monitors the plant during working hours;
   • who monitors it outside working hours;
   • which alarms require immediate action;
   • which alarms are informational;
   • how alarms are acknowledged and escalated;
   • who may close an alarm;
   • which events require Owner notification;
   • which events require TSO, DSO, regulatory or cybersecurity escalation.

3. Dispatching and market operation. Define:

   • who creates market schedules;
   • who submits nominations or offers;
   • who converts market results into plant instructions;
   • who approves dispatch instructions;
   • how active-power, reactive-power and availability instructions reach the plant;
   • how state-of-charge and technical constraints are communicated back to market-facing systems;
   • which party is responsible when the plant cannot execute a requested programme.

4. Command authority and operating priority. Define the hierarchy among:

   • local operator commands;
   • Owner-originated instructions;
   • market or aggregator instructions;
   • TSO or DSO commands;
   • automatic EMS/PPC control;
   • protection and safety functions;
   • emergency local actions;
   • maintenance or commissioning commands.

   Conflicts must be resolved by an explicit priority model rather than by whichever signal happens to arrive last.

5. Operating modes. Define the permitted plant modes, such as:

   • normal market operation;
   • balancing-service operation;
   • grid-support operation;
   • standby;
   • maintenance;
   • commissioning;
   • degraded communication;
   • local-only control;
   • emergency shutdown;
   • cyber-isolation mode;
   • recovery mode.

   For each mode, define allowed commands, available services, responsible operators and transition conditions.

6. Remote maintenance and support. Define:

   • who may request remote access;
   • who approves it;
   • which systems may be accessed;
   • whether access is read-only, engineering or administrative;
   • how long access may remain active;
   • how sessions are monitored and recorded;
   • how access is terminated;
   • what happens when the PAM, VPN or remote-support platform is unavailable.

7. Degraded and emergency operation. Define plant behaviour during:

   • loss of the Owner connection;
   • loss of market-platform connectivity;
   • loss of TSO or DSO communication;
   • EMS or PPC failure;
   • SCADA failure;
   • loss of time synchronization;
   • loss of a Power Island controller;
   • telecom failure;
   • cybersecurity incident;
   • loss of cloud or vendor services;
   • partial battery or PCS unavailability.

The ConOps should produce the following actionable outputs:

• actor and role matrix;
• operating-mode catalogue;
• command-priority matrix;
• alarm and escalation matrix;
• remote-access approval workflow;
• degraded-mode and emergency-operation scenarios;
• operational acceptance scenarios for FAT, SAT and proving.

The ConOps should not be accepted if important decisions remain expressed as to be agreed during commissioning or depend on undocumented supplier behaviour.

Requirements baseline

The requirements baseline converts Owner objectives, operating scenarios, regulations, grid codes, contracts and risk assessments into numbered and testable project requirements. Each requirement should be:

• clear;
• uniquely identified;
• attributable to a source;
• allocated to an accountable party;
• capable of objective verification;
• linked to an acceptance criterion;
• maintained under change control.

Requirements should be organized across at least the following domains:

1. Commercial and market operation. Cover:

   • dispatching functionality;
   • charging and discharging schedules;
   • reserve and balancing-service participation;
   • availability declarations;
   • state-of-charge visibility;
   • derating and constraint communication;
   • performance and settlement data;
   • data exchange with BRPs, BSPs, traders and aggregators.

2. Grid connection and grid-code compliance. Cover:

   • active- and reactive-power control;
   • voltage and frequency support;
   • response times;
   • TSO/DSO signal exchange;
   • telecontrol;
   • measurements;
   • protection coordination;
   • fallback and fail-safe behaviour;
   • evidence required to demonstrate grid-code compliance.

3. Safety. Cover:

   • emergency stop;
   • protection actions;
   • fire and gas detection;
   • thermal events;
   • electrical isolation;
   • interaction among BMS, PCS, EMS/PPC and BoP systems;
   • priority of safety functions over operational commands.

4. Cybersecurity. Cover:

   • zones and conduits;
   • access control;
   • remote access;
   • command-path protection;
   • identity and credentials;
   • logging and monitoring;
   • secure protocols;
   • vulnerability and patch management;
   • backup and recovery;
   • incident response;
   • supplier and cloud controls.

5. Physical security. Cover:

   • perimeter protection;
   • access control;
   • intrusion detection;
   • video surveillance;
   • equipment-room security;
   • anti-tamper controls;
   • physical protection of telecom and control infrastructure.

6. Availability and resilience. Cover:

   • redundancy;
   • failover;
   • single points of failure;
   • telecom diversity;
   • degraded operating modes;
   • recovery objectives;
   • external-service dependencies;
   • resilience under combined physical and cyber events.

7. Maintainability and support. Cover:

   • diagnostic access;
   • engineering tools;
   • spare parts;
   • configuration backups;
   • software and firmware support;
   • obsolescence;
   • end-of-support notification;
   • restoration of supplier-specific applications.

8. Data and evidence. Cover:

   • Owner access to operational data;
   • data export;
   • logs and forensic evidence;
   • retention;
   • timestamp quality;
   • battery-passport data;
   • configuration records;
   • FAT/SAT evidence;
   • audit and investigation support.

9. Operational handover. Cover:

   • as-built documentation;
   • credentials;
   • certificates and keys;
   • source or project files;
   • backup baselines;
   • restore procedures;
   • inventories;
   • licences;
   • training;
   • residual risks;
   • support and escalation contacts.

A practical requirement record should include:

Field	Required content
Requirement ID	Unique identifier
Source	Owner objective, regulation, grid code, contract, standard or risk assessment
Requirement statement	Clear and testable shall statement
Applicability	System, interface, asset, service or process affected
Responsible party	Party accountable for implementation
Verification method	Inspection, analysis, demonstration or test
Verification phase	Design review, FAT, SAT or operational proving
Expected result	Objective acceptance criterion
Evidence	Required record, export, log, test result or certificate
Status	Draft, approved, implemented, verified, deviated or closed

The baseline should not contain non-verifiable statements such as the system shall use industry best practice unless the applicable practice and acceptance criterion are explicitly identified.

Functional architecture

The functional architecture describes what the plant must do before deciding which product performs each function. This distinction prevents product names from substituting for system design.

For example, specifying an EMS product does not by itself define:

• which commands it accepts;
• which constraints it validates;
• how it interacts with the PPC;
• whether it is the authoritative command-governance point;
• how it behaves when disconnected from the cloud;
• which logs it generates;
• how it is restored.

The functional architecture should define, at minimum, the following functions:

1. Plant energy-management function. Define responsibility for:

   • schedule execution;
   • state-of-charge management;
   • active-power control;
   • plant constraints;
   • availability calculation;
   • optimization inputs;
   • external command validation.

2. Power-plant control function. Define responsibility for:

   • grid-code control loops;
   • active- and reactive-power regulation;
   • voltage and frequency response;
   • allocation of setpoints among Power Islands or PCS units;
   • response to TSO/DSO signals.

3. SCADA and operator-supervision function. Define:

   • HMI;
   • alarm presentation;
   • trends;
   • event management;
   • local command capability;
   • operator authentication;
   • operating-mode selection;
   • interaction with EMS/PPC functions.

4. Battery-management function. Define:

   • battery safety;
   • state-of-charge and state-of-health calculation;
   • alarms and faults;
   • charge/discharge limits;
   • derating;
   • isolation and shutdown behaviour;
   • diagnostic interfaces.

5. Power-conversion function. Define:

   • DC/AC conversion;
   • local control loops;
   • protection;
   • current and power limits;
   • response to plant-level setpoints;
   • fallback behaviour during loss of upper-level control.

6. Grid-interface and telecontrol function. Define:

   • TSO/DSO communications;
   • RTU or gateway functions;
   • signal conversion;
   • measurement exchange;
   • dispatch-order reception;
   • separation between operational telecontrol and administration.

7. Data and integration function. Define:

   • historian;
   • message brokers;
   • APIs;
   • telemetry export;
   • market and Owner interfaces;
   • cloud integration;
   • data buffering;
   • data quality;
   • data ownership and retention.

8. Cybersecurity and infrastructure services. Define:

   • identity and access management;
   • PAM and jump-host services;
   • logging and SIEM;
   • IDS/DPI;
   • endpoint protection;
   • time synchronization;
   • backup and recovery;
   • configuration management;
   • vulnerability and patch management.

For each function, the architecture should identify:

• purpose;
• inputs;
• outputs;
• authoritative source;
• dependent functions;
• responsible organization;
• allocated system or product;
• failure behaviour;
• degraded mode;
• security requirements;
• test method.

The resulting output should include a functional block diagram and a function-allocation matrix mapping each function to:

• primary system;
• secondary or redundant system;
• responsible supplier;
• responsible operator;
• relevant requirements;
• relevant interfaces;
• FAT/SAT tests.

A product may implement several functions, and one function may depend on several products. The architecture must make those relationships explicit.

Interface-control model

Interfaces are the principal source of integration risk. They should be treated as controlled design objects, not as informal connections agreed between suppliers.

The project should maintain an Interface Control Document or equivalent interface register covering all material:

• electrical interfaces;
• network interfaces;
• software interfaces;
• protocol interfaces;
• data interfaces;
• command interfaces;
• cloud interfaces;
• operational interfaces;
• organizational hand-offs.

Each interface record should define:

1. Endpoints. Identify:

   • source system;
   • destination system;
   • source zone;
   • destination zone;
   • responsible suppliers;
   • responsible operators.

2. Communication initiation. Define:

   • which endpoint initiates communication;
   • whether communication is periodic, event-driven or on demand;
   • whether reverse communication is permitted;
   • whether the interface remains active continuously.

3. Protocol and transport. Define:

   • application protocol;
   • transport protocol;
   • ports;
   • addressing;
   • encryption;
   • authentication;
   • certificate or key requirements;
   • protocol-specific security limitations.

4. Information exchanged. Define:

   • signal or data list;
   • units;
   • scaling;
   • quality flags;
   • timestamps;
   • update rates;
   • data ownership;
   • retention requirements.

5. Authority and direction. Classify the interface as:

   • telemetry-only;
   • read/write;
   • command-capable;
   • engineering;
   • administrative;
   • logging;
   • backup;
   • time synchronization.

6. Operational behaviour. Define:

   • normal response;
   • timeout;
   • retry behaviour;
   • duplicate handling;
   • stale-data treatment;
   • communication-loss behaviour;
   • fallback state;
   • alarm generation.

7. Cybersecurity controls. Define:

   • allow-listing;
   • identity requirements;
   • authorization;
   • integrity and confidentiality;
   • logging;
   • monitoring;
   • rate limiting;
   • replay protection;
   • session restrictions.

8. Verification. Define:

   • FAT test;
   • SAT test;
   • expected positive result;
   • expected negative result;
   • required evidence;
   • responsible tester;
   • acceptance authority.

A practical interface record should contain at least:

Field	Required content
Interface ID	Unique controlled identifier
Source / destination	Systems, zones and responsible parties
Initiator	Endpoint that starts communication
Purpose	Business or operational reason for the interface
Protocol / port	Full communication stack
Data or signal list	Approved exchanged information
Authority classification	Telemetry, command, engineering, administration or service flow
Security controls	Authentication, encryption, allow-listing and monitoring
Failure behaviour	Timeout, fallback, alarm and recovery
Logging	Events and evidence to be retained
Verification	FAT/SAT method and expected result
Status	Proposed, approved, implemented, verified or deviated

An interface should not be implemented until its record has been approved by all parties responsible for the two endpoints and by the accountable system integrator.

Command-authority model

The command-authority model defines every mechanism capable of influencing plant behaviour. This includes not only explicit setpoint commands, but also:

• schedules;
• availability declarations;
• mode changes;
• enable and disable functions;
• resets;
• limit changes;
• configuration changes;
• firmware updates;
• automatic optimization;
• fallback actions;
• emergency actions.

The model should define the following:

1. All command sources. Identify:

   • local HMI;
   • Owner control platform;
   • EMS;
   • PPC;
   • TSO/DSO telecontrol;
   • trader or aggregator platform;
   • engineering workstation;
   • remote-service platform;
   • vendor cloud;
   • protection system;
   • automated optimization or AI function.

2. Authorized command-governance point. Define where external or higher-level instructions are:

   • authenticated;
   • authorized;
   • checked;
   • prioritized;
   • translated;
   • logged;
   • accepted or rejected.

   External systems should not directly control field devices unless a specific safety or regulatory architecture explicitly requires it.

3. Command categories. Classify commands by risk and function, for example:

   • active-power setpoints;
   • reactive-power setpoints;
   • charge/discharge schedules;
   • operating-mode changes;
   • start/stop;
   • reset;
   • maintenance commands;
   • safety commands;
   • protection actions;
   • emergency shutdown.

4. Validation rules. Define checks for:

   • source authorization;
   • command type;
   • command range;
   • state of charge;
   • battery and PCS limits;
   • plant availability;
   • grid-code constraints;
   • safety constraints;
   • timestamp validity;
   • duplicate commands;
   • replay attempts;
   • current operating mode;
   • command priority.

5. Conflict resolution. Define priority among:

   • safety and protection actions;
   • TSO/DSO instructions;
   • Owner dispatch;
   • local operator commands;
   • market schedules;
   • EMS optimization;
   • maintenance actions.

6. Failure and fallback. Define behaviour during:

   • command-channel loss;
   • delayed command;
   • invalid command;
   • conflicting instructions;
   • EMS/PPC failure;
   • loss of Owner or market connectivity;
   • cyber incident;
   • local takeover.

7. Evidence. Log at least:

   • command origin;
   • authenticated identity;
   • timestamp;
   • original value;
   • validation result;
   • rejection reason;
   • translated plant command;
   • execution result;
   • resulting plant response;
   • operator acknowledgement where applicable.

The actionable outputs should include:

• command-source register;
• command-priority matrix;
• command-path diagram;
• command-validation matrix;
• command/protocol register;
• positive and negative command-test catalogue;
• emergency and fallback command procedures.

The command model should be tested end to end. Demonstrating that a register can be written is not sufficient; the project must demonstrate that only the intended party can cause the intended plant behaviour under the intended conditions.

Cybersecurity architecture

The cybersecurity architecture should be derived from the functional architecture, command model and interface register. Its purpose is to establish which systems may trust, communicate with, administer or influence each other. It should include the following:

1. System boundary and trust domains. Define:

   • plant cybersecurity boundary;
   • remote and cloud boundary;
   • Owner systems;
   • vendor systems;
   • TSO/DSO systems;
   • market and aggregator systems;
   • supplier responsibility boundaries.

2. Zones and sub-zones. Separate functions such as:

   • ESS/BMS;
   • PCS and Power Island control;
   • OT Core and EMS/PPC;
   • Supervisory;
   • Engineering/Maintenance;
   • OT DMZ;
   • management;
   • TSO/DSO telecontrol;
   • Aux-IT;
   • remote service;
   • Owner platforms;
   • cloud/vendor platforms.

3. Conduit matrix. For each permitted flow, define:

   • source;
   • destination;
   • purpose;
   • protocol;
   • initiator;
   • authority classification;
   • authentication;
   • encryption;
   • logging;
   • monitoring;
   • test method.

4. Prohibited-path matrix. Explicitly identify paths that must not exist, such as:

   • direct cloud-to-OT access;
   • direct vendor access to field devices;
   • TSO/DSO administration of plant systems;
   • supervisory access to unrestricted field networks;
   • engineering bypass of the approved maintenance path;
   • telemetry conduits carrying commands;
   • backup clients administering repositories;
   • direct internet access from OT systems.

5. Management-plane architecture. Define:

   • administrative entry points;
   • jump hosts;
   • PAM;
   • named accounts;
   • MFA;
   • session recording;
   • privilege elevation;
   • emergency access;
   • local administration;
   • management-network separation.

6. Identity and credential model. Define:

   • account types;
   • roles;
   • ownership;
   • password and certificate policies;
   • service accounts;
   • shared-account prohibition;
   • credential handover;
   • revocation;
   • periodic review.

7. Logging and monitoring. Define:

   • required log sources;
   • event categories;
   • log format;
   • timestamp source;
   • buffering;
   • forwarding;
   • SIEM integration;
   • IDS/DPI coverage;
   • alert escalation;
   • retention.

8. Vulnerability, patch and secure-update model. Define:

   • asset and software inventory;
   • vulnerability sources;
   • supplier-notification obligations;
   • patch assessment;
   • testing;
   • deployment windows;
   • rollback;
   • compensating controls;
   • end-of-support treatment.

9. Cloud and vendor-service controls. Define:

   • approved endpoints;
   • data categories;
   • command capability;
   • geographic processing;
   • retention;
   • remote-support paths;
   • subcontractors;
   • incident notification;
   • exit and data-retrieval procedures.

10. Cybersecurity verification. Define tests for:

• permitted flows;
• prohibited paths;
• access control;
• session recording;
• log generation;
• SIEM forwarding;
• failover;
• certificate handling;
• backup integrity;
• incident isolation;
• restoration.

The architecture should result in controlled diagrams, matrices and configuration requirements. It should not remain a conceptual zone diagram disconnected from actual VLANs, routes, firewall rules, accounts, interfaces and tests.

Recovery model

Recovery design should begin with the plant functions that must be restored and the time within which they must return. It should not begin with the selection of a backup product. The recovery model should define the following:

1. Recovery scope. Identify all items required to restore operation, including:

   • EMS/PPC applications;
   • SCADA servers;
   • HMI configurations;
   • PLC and controller programs;
   • BMS and PCS configurations where accessible;
   • firewall and switch configurations;
   • PAM and identity configurations;
   • historian and databases;
   • certificates and keys;
   • licences;
   • engineering project files;
   • virtual machines;
   • cybersecurity policies;
   • documentation and evidence.

2. Recovery priorities. Define the restoration order based on operational dependencies.

   A typical sequence may include:

   1. power and infrastructure services;
   2. network and security boundaries;
   3. time synchronization;
   4. identity and privileged access;
   5. OT Core and EMS/PPC;
   6. Power Island and controller communication;
   7. SCADA and HMI;
   8. TSO/DSO interfaces;
   9. logging and monitoring;
   10. market and Owner interfaces;
   11. historian and non-critical services.

   The final order must reflect the actual plant architecture.

3. Recovery objectives. Define for each system:

   • Recovery Time Objective;
   • Recovery Point Objective;
   • maximum tolerable outage;
   • required backup frequency;
   • retention;
   • required restoration evidence.

4. Trusted recovery baseline. Define:

   • approved software and firmware versions;
   • known-good configurations;
   • clean installation media;
   • verified hashes;
   • protected credentials;
   • certificate and key recovery;
   • malware-free restoration process.

5. Backup architecture. Define:

   • backup sources;
   • repositories;
   • network paths;
   • encryption;
   • immutability or deletion protection;
   • access roles;
   • offline or isolated copies;
   • monitoring;
   • failure alarms;
   • retention.

6. Restore procedures. Define:

   • responsible personnel;
   • required tools;
   • credentials;
   • dependencies;
   • step-by-step procedures;
   • integrity checks;
   • validation after restoration;
   • rollback if restoration fails.

7. Degraded operation. Define how the plant operates while recovery is incomplete, including:

   • local control;
   • reduced market participation;
   • manual procedures;
   • isolated operation;
   • reduced monitoring;
   • temporary logging;
   • communication with the Owner and TSO/DSO.

8. Recovery testing. Define:

   • component restore tests;
   • application restore tests;
   • full-system recovery exercises;
   • cyber-incident recovery scenarios;
   • frequency;
   • expected results;
   • evidence;
   • corrective-action process.

The recovery model should produce:

• recovery-priority matrix;
• RTO/RPO register;
• backup-scope matrix;
• dependency diagram;
• trusted-baseline register;
• restore procedures;
• degraded-mode procedures;
• recovery-test plan;
• retained recovery evidence.

A successful backup job is not evidence of recoverability. Recoverability is demonstrated only when the system can be restored, validated and returned to an approved operational state within the required time and data-loss limits.

Design completion criteria

The stronger design phase should not be considered complete merely because the documents above exist. It should be considered complete only when:

• the ConOps is approved by the parties responsible for operation;
• the requirements baseline is complete, numbered and testable;
• functions are allocated to systems and suppliers;
• material interfaces have approved interface records;
• command authority and priority are explicit;
• cybersecurity zones and conduits are mapped to the detailed network design;
• recovery priorities and objectives are approved;
• configurations can be derived from the design;
• FAT and SAT procedures can be traced to requirements;
• open assumptions, defects and deviations are recorded;
• the accountable system integrator confirms readiness to freeze the implementation baseline.

At that point, the project has moved beyond an accumulation of drawings and supplier documents. It has produced an integrated design that can be implemented, verified, validated and accepted.

FAT and SAT must become verification and validation phases

The stronger design phase produces requirements, architectures, interface records, command rules, cybersecurity controls and recovery objectives. FAT and SAT must convert those artefacts into objective evidence.

They should not be treated as final demonstrations performed after the technical solution has already been accepted in practice. Nor should they be reduced to proving that devices power on, signals are visible and commands can be transmitted.

For a BESS project, FAT and SAT must determine whether:

• each component conforms to its approved specification;
• interacting subsystems behave correctly together;
• the as-built plant matches the approved design baseline;
• end-to-end operational processes satisfy Owner objectives;
• unauthorized, unsafe and unintended behaviours are prevented;
• degraded operation, failover and recovery are effective;
• the evidence required for acceptance and operation is complete.

The analogy with software testing is useful because software projects distinguish component, integration, system and acceptance testing. Terms such as alpha and beta, however, should not be copied mechanically into infrastructure projects. BESS delivery requires a more explicit relationship among factory verification, site verification, integrated validation and operational proving.

The testing lifecycle should include at least the following phases:

Phase	Primary objective	Main test environment	Principal evidence
Component FAT	Verify individual products and configurations	Supplier or integrator factory	Configuration exports, test records, logs and certificates
Subsystem FAT	Verify integrated subsystem behaviour	Factory bench, simulator or hardware-in-the-loop environment	Interface tests, command traces, alarms and failure-response evidence
Cybersecurity FAT	Verify controls and prohibited behaviours before shipment	Representative factory architecture	Firewall, access, logging, negative-test and recovery evidence
Site installation verification	Confirm that the installed plant matches the approved baseline	Actual plant before integrated SAT	As-built inventory, configuration comparison and connectivity evidence
Integrated SAT	Verify complete end-to-end behaviour in the as-built plant	Actual operational architecture	System test records, logs, command traces and failover evidence
Operational validation	Validate fitness for intended use with real roles and workflows	Controlled operational environment	Proving-period results, operator records and acceptance evidence
Recovery and resilience validation	Demonstrate restoration and degraded operation	Factory and site, depending on scenario	Restore records, recovery times and continuity evidence

The testing model should preserve the relationship between design decomposition and system integration:

%%{init: {"theme": "neo", "look": "handDrawn", "layout": "elk"}}%%
flowchart TB
    O["Owner objectives and ConOps"] --> SR["System requirements"]
    SR --> AR["Functional, control, cybersecurity and resilience architecture"]
    AR --> SS["Subsystem and interface specifications"]
    SS --> CB["Configuration baseline"]
    CB --> IM["Implementation"]

    IM --> CF["Component FAT"]
    CF --> IF["Subsystem, interface and cybersecurity FAT"]
    IF --> SV["Site installation verification"]
    SV --> ST["Integrated SAT"]
    ST --> RV["Resilience and recovery validation"]
    RV --> OV["Operational validation and proving"]

    CF -. verifies .-> SS
    IF -. verifies .-> AR
    ST -. verifies .-> SR
    OV -. validates .-> O

Figure 3: A BESS verification and validation model linking design decomposition to FAT, SAT and operational proving.

Testing must be planned before implementation

FAT and SAT procedures should be developed while the corresponding requirements and interfaces are being designed. The project should not wait until equipment is installed before deciding:

• what must be tested;
• what constitutes success;
• which parties must participate;
• what simulators are required;
• which logs must be collected;
• how failures will be induced;
• how prohibited paths will be demonstrated;
• which evidence the Owner will receive.

Each test case should be linked to one or more approved requirements. A practical test record should include:

Field	Required content
Test ID	Unique controlled identifier
Requirement references	Requirements verified or validated by the test
Design references	Architecture, interface record, command rule or configuration baseline
Objective	Property or behaviour being demonstrated
Preconditions	Required plant state, configuration, identities and test data
Test environment	Factory bench, simulator, hardware-in-the-loop system or actual plant
Procedure	Controlled sequence of actions
Expected result	Objective pass/fail criterion
Evidence	Logs, screenshots, packet captures, configuration exports, measurements or records
Responsible tester	Party executing the test
Witnesses	Owner, integrator, supplier, grid operator or independent assessor
Result	Pass, fail, blocked or conditionally accepted
Defect reference	Associated defect or deviation, where applicable
Re-test status	Required corrective action and re-test result
Acceptance authority	Party authorized to approve closure

The test procedure should be reproducible. Another competent party should be able to repeat it using the same baseline and obtain the same conclusion.

FAT entry criteria

FAT should not begin merely because equipment is available. The FAT readiness review should confirm that:

• the requirements baseline is approved;
• the relevant architecture and interface records are approved;
• the command-authority model is sufficiently complete;
• the software and firmware versions are declared;
• the configuration baseline is frozen;
• test procedures and expected results are approved;
• required simulators and test tools are available;
• test accounts, certificates and credentials are prepared;
• log collection and evidence storage are active;
• known limitations and open items are recorded;
• the parties responsible for execution and witnessing are identified.

Testing an unstable or undocumented configuration produces evidence of limited value. Any change to the tested baseline should be assessed to determine whether partial or complete re-testing is required.

Component FAT

Component FAT verifies that an individual product or configured component conforms to the approved specification before it is relied upon by the larger system.

Depending on the component, the test scope should include the following:

1. Product identity and lifecycle status. Verify:

   • manufacturer and model;
   • hardware revision;
   • firmware and software versions;
   • licence status;
   • support period;
   • known end-of-support date;
   • declared vulnerabilities and limitations.

   The purpose is to establish exactly which product baseline has been tested and will be installed.

2. Configuration baseline. Verify:

   • network settings;
   • enabled and disabled services;
   • application parameters;
   • security policies;
   • local users and roles;
   • certificates and keys;
   • time source;
   • log destination;
   • backup or export settings.

   The tested configuration should be exported, hashed where appropriate and retained as the reference baseline.

3. Identity and access controls. Verify:

   • named accounts;
   • role separation;
   • default-account treatment;
   • password and authentication policies;
   • service accounts;
   • privilege restrictions;
   • account lockout or equivalent controls;
   • local emergency access.

4. Protocol and communication behaviour. Verify:

   • required protocols;
   • disabled insecure services;
   • authentication;
   • encryption where required;
   • supported sessions;
   • connection loss;
   • timeout;
   • retry and reconnection behaviour.

5. Logging and monitoring. Verify that the component generates the events required for:

   • authentication;
   • authorization;
   • configuration changes;
   • command execution;
   • faults and alarms;
   • restart and shutdown;
   • communication loss;
   • security events.

   Logs should contain usable timestamps, source identities and event outcomes.

6. Backup and restoration capability. Verify that:

   • configurations can be exported;
   • applications and databases can be backed up where applicable;
   • a clean restoration can be performed;
   • restored components match the approved baseline;
   • required credentials, keys and licences are available.

7. Failure and failover behaviour. Verify, where applicable:

   • redundant power supplies;
   • redundant network interfaces;
   • active/passive failover;
   • restart behaviour;
   • retention of configuration after reboot;
   • alarm generation after failure;
   • restoration to a controlled state.

8. Security hardening and product limitations. Verify the implemented hardening against the project baseline and record any function that cannot meet the required security property.

A supplier statement that a feature is supported is not equivalent to test evidence that the feature operates correctly in the selected version and configuration. The actionable outputs of component FAT should include:

• approved component test report;
• final configuration export;
• software and firmware inventory;
• account and role record;
• known-limitations register;
• backup and restore evidence;
• unresolved defect list;
• shipment or integration release decision.

Subsystem and interface FAT

Subsystem FAT verifies interactions among components that together provide an operational function. This phase is essential because many BESS failures occur at supplier boundaries rather than inside individual products.

The test environment should reproduce the relevant architecture as closely as practical through:

• actual equipment;
• software simulators;
• protocol emulators;
• hardware-in-the-loop systems;
• representative switches and firewalls;
• representative latency and communication constraints;
• actual authentication and certificate mechanisms.

The subsystem FAT scope should include at least the following integration areas:

1. BMS and PCS interaction. Verify:

   • battery availability;
   • charge and discharge limits;
   • current and voltage limits;
   • alarms and faults;
   • state-of-charge information;
   • derating;
   • stop and isolation behaviour;
   • communication-loss response.

2. EMS/PPC and Power Island interaction. Verify:

   • setpoint allocation;
   • active- and reactive-power control;
   • plant constraints;
   • availability feedback;
   • mode changes;
   • response timing;
   • fallback behaviour;
   • treatment of partial unit unavailability.

3. SCADA and EMS/PPC interaction. Verify:

   • telemetry;
   • alarms and events;
   • operator commands;
   • mode selection;
   • command validation;
   • command acknowledgement;
   • trend and historian data;
   • user-role restrictions.

4. Grid-interface and telecontrol interaction. Verify:

   • measurement exchange;
   • status and alarm signals;
   • telecontrol commands;
   • quality flags;
   • timestamps;
   • communication loss;
   • fallback behaviour;
   • separation between telecontrol and administration.

5. Owner, market and aggregator interfaces. Verify:

   • telemetry export;
   • schedules;
   • dispatch instructions;
   • state-of-charge and availability feedback;
   • authentication;
   • command approval;
   • rejection of invalid inputs;
   • buffering and recovery after communication loss.

6. Cybersecurity services. Verify:

   • PAM-mediated access;
   • session recording;
   • SIEM forwarding;
   • IDS/DPI visibility;
   • endpoint-security operation;
   • time synchronization;
   • backup paths;
   • security alarms and escalation.

7. Alarm and event correlation. Verify that events across BMS, PCS, EMS/PPC, SCADA, network and security systems can be correlated using consistent:

   • timestamps;
   • asset identifiers;
   • alarm priorities;
   • event codes;
   • command identifiers;
   • operator identities.

Subsystem FAT should demonstrate not merely that messages are exchanged, but that the complete interface semantics are correct. For each material interface, the test should validate:

• values;
• units;
• scaling;
• direction;
• update rate;
• quality;
• timestamps;
• timeout behaviour;
• authority;
• failure response;
• logging.

The actionable outputs should include:

• subsystem FAT report;
• completed interface-test matrix;
• signal and protocol verification records;
• end-to-end command traces;
• alarm and event evidence;
• failure-response evidence;
• approved deviations;
• updated configuration baseline.

Positive and negative testing

A secure and resilient plant cannot be accepted through positive tests alone. Positive tests demonstrate that authorized behaviour works. Examples include:

• approved telemetry reaches the correct destination;
• an authorized command is accepted;
• the EMS/PPC validates and executes a valid setpoint;
• a named remote user reaches an approved maintenance target through PAM;
• logs reach the collector;
• backups complete;
• failover occurs within the required time.

Negative tests demonstrate that unauthorized, unsafe or unintended behaviour is prevented. The project should test at least the following categories:

1. Command rejection. Demonstrate rejection of:

   • unauthorized commands;
   • stale commands;
   • duplicated commands;
   • malformed commands;
   • out-of-range values;
   • commands incompatible with the current operating mode;
   • commands violating state-of-charge, battery, PCS or grid constraints;
   • replayed instructions.

2. Access-control enforcement. Demonstrate that:

   • unauthorized users cannot authenticate;
   • authorized users cannot exceed their assigned role;
   • remote users cannot bypass PAM;
   • temporary access expires;
   • shared or default accounts are disabled or controlled;
   • SOC/NOC users cannot administer plant assets unless explicitly authorized.

3. Network and conduit enforcement. Demonstrate that:

   • cloud platforms cannot directly poll OT systems unless explicitly designed and approved;
   • market platforms cannot reach field devices;
   • telemetry conduits cannot carry commands;
   • TSO/DSO paths cannot become maintenance paths;
   • engineering workstations cannot reach unintended targets;
   • OT systems cannot access the public internet directly;
   • prohibited lateral movement between zones is blocked.

4. Management-plane separation. Demonstrate that:

   • runtime networks cannot administer firewalls, switches or servers;
   • operational protocols cannot access management interfaces;
   • backup clients cannot administer or delete backup repositories;
   • time clients cannot administer time servers;
   • monitoring platforms cannot become administrative paths.

5. Logging and detection. Demonstrate that:

   • denied connections are logged;
   • failed authentication is recorded;
   • unauthorized command attempts generate evidence;
   • configuration changes are visible;
   • IDS/DPI detects representative prohibited or anomalous traffic;
   • loss of log forwarding generates an alarm.

6. Failure of security controls. Test behaviour when:

   • SIEM forwarding is unavailable;
   • IDS/DPI monitoring is interrupted;
   • PAM is unavailable;
   • certificate validation fails;
   • the time source is lost;
   • an endpoint-security agent is disabled;
   • a firewall member fails over.

The test should prove that loss of a security service does not silently create broader access or uncontrolled operation. Negative tests should be planned with the same rigor as functional tests. Their expected result is usually the absence of a capability, and that absence must be evidenced through logs, packet captures, firewall records, application responses or other objective means.

FAT exit criteria

FAT completion should require more than execution of the planned test procedures. The FAT exit review should confirm that:

• all mandatory tests have been executed;
• each result is linked to the approved requirement;
• the tested configuration baseline is retained;
• unresolved defects are classified;
• deviations have been formally assessed;
• safety- or command-critical failures are closed;
• cybersecurity-critical failures are closed or explicitly rejected from shipment;
• required re-tests have been completed;
• FAT evidence is complete and accessible to the Owner;
• changes required before SAT are controlled;
• the system is formally released for site installation.

Conditional FAT acceptance should identify:

• the unresolved item;
• responsible party;
• corrective action;
• due date;
• affected requirement;
• operational or cybersecurity impact;
• required re-test;
• condition preventing final acceptance.

A test should not be recorded as passed when the expected result was not achieved. The correct result is failed, blocked or conditionally accepted with an approved deviation.

Site installation verification

Before integrated SAT begins, the project must establish that the installed plant matches the configuration and architecture verified during FAT. This stage is not a repetition of factory testing. It is an as-built conformity check. The site verification should cover the following:

1. Asset identity. Confirm:

   • manufacturer;
   • model;
   • serial number;
   • hardware revision;
   • software and firmware versions;
   • installed licences;
   • physical location;
   • network identity.

2. Network implementation. Confirm:

   • VLANs;
   • subnets;
   • gateways;
   • routes;
   • switch ports;
   • trunks;
   • firewall zones;
   • firewall policies;
   • NAT rules where applicable;
   • out-of-band management;
   • redundant network paths.

3. Security controls. Confirm:

   • accounts and roles;
   • MFA;
   • PAM paths;
   • certificates;
   • log forwarding;
   • IDS/DPI visibility;
   • endpoint protection;
   • backup destinations;
   • time sources;
   • remote-access paths.

4. Physical installation. Confirm:

   • rack position;
   • power feeds;
   • redundant power;
   • patching;
   • fibre paths;
   • labelling;
   • environmental conditions;
   • tamper protection;
   • physical separation where required.

5. Configuration comparison. Compare the as-built configuration against the FAT baseline using:

   • exported configurations;
   • checksums;
   • automated configuration comparison where available;
   • manual inspection for unsupported devices;
   • documented change records.

6. Monitoring visibility. Confirm:

   • SPAN, mirror or TAP configuration;
   • monitored conduits;
   • traffic visibility;
   • sensor health;
   • alert delivery;
   • failure alarms.

Any site change made after FAT should be recorded and assessed for re-testing. The actionable outputs should include:

• as-built asset inventory;
• FAT-to-site configuration comparison;
• approved site-change register;
• physical and network inspection report;
• readiness decision for integrated SAT.

Integrated SAT

Integrated SAT verifies the complete plant in its actual physical, network and operational environment. It should demonstrate that the end-to-end system satisfies the approved system requirements, not merely that individual suppliers have completed their local commissioning activities. The SAT scope should include the following:

1. End-to-end telemetry. Verify the complete path from field devices and controllers to:

   • SCADA/HMI;
   • EMS/PPC;
   • historian;
   • Owner platform;
   • market or aggregator platform;
   • TSO/DSO interface;
   • SOC/SIEM where applicable.

   Confirm values, timestamps, quality, scaling, latency, buffering and recovery after communication loss.

2. End-to-end commands. Verify:

   • authorized command origin;
   • authentication;
   • command-governance processing;
   • validation;
   • setpoint allocation;
   • execution;
   • plant response;
   • acknowledgement;
   • logging;
   • rejection of invalid commands.

3. Operating modes and transitions. Test:

   • normal operation;
   • standby;
   • charging;
   • discharging;
   • grid-support modes;
   • maintenance;
   • local control;
   • remote control;
   • degraded communication;
   • emergency shutdown;
   • recovery.

   Confirm that transitions are authorized, deterministic and logged.

4. Grid and market integration. Verify:

   • TSO/DSO communication;
   • dispatch-order handling;
   • schedules and nominations where testable;
   • availability and constraint exchange;
   • active- and reactive-power response;
   • response timing;
   • behaviour during partial plant unavailability.

5. Remote access. Verify the actual remote-access path using real:

   • identities;
   • MFA;
   • approval workflows;
   • PAM policies;
   • target restrictions;
   • session recording;
   • logging;
   • expiry and revocation.

6. Cybersecurity monitoring. Verify:

   • log generation;
   • SIEM forwarding;
   • IDS/DPI visibility;
   • endpoint-security alerts;
   • account events;
   • configuration-change events;
   • prohibited-path attempts;
   • escalation to responsible parties.

7. Failover and degraded operation. Test representative failures involving:

   • servers;
   • network links;
   • firewall members;
   • switches;
   • telecom services;
   • time sources;
   • external platforms;
   • cloud services;
   • Power Island controllers;
   • logging and monitoring services.

8. Prohibited paths. Repeat the critical negative tests in the as-built environment. The actual plant must demonstrate that unauthorized paths remain absent after installation, local configuration changes and network integration.

The SAT environment should use the final, or explicitly controlled near-final:

• topology;
• addresses;
• firewall rules;
• accounts;
• certificates;
• software versions;
• logging destinations;
• backup targets;
• remote-access services.

A SAT executed against temporary commissioning accounts, broad firewall rules or incomplete security services does not demonstrate the acceptability of the final plant.

Resilience and recovery validation

Resilience testing should demonstrate that the plant can continue operating in an approved degraded state or recover within its defined objectives. The test programme should include scenarios such as:

• loss of one control server;
• loss of one network path;
• firewall failover;
• telecom-provider failure;
• loss of TSO/DSO communication;
• loss of Owner or market connectivity;
• loss of time synchronization;
• loss of historian or log collector;
• loss of PAM or remote-access services;
• corruption of a configuration;
• loss of a virtual machine;
• cybersecurity isolation of a compromised zone;
• restoration from a trusted backup.

For each scenario, the test should verify:

1. detection of the failure;
2. alarm generation;
3. operational impact;
4. automatic or manual fallback;
5. authority to initiate recovery;
6. recovery procedure;
7. achieved recovery time;
8. achieved recovery point;
9. integrity of the restored configuration;
10. return to normal operation;
11. retained evidence.

Recovery validation should include actual restoration, not only inspection of backup-job reports. At minimum, the project should demonstrate restoration of representative critical systems such as:

• EMS/PPC;
• SCADA;
• controller project or configuration;
• firewall configuration;
• switch configuration;
• virtual machine;
• application database;
• historian segment;
• PAM configuration;
• certificate or key material where safely testable.

Where a full destructive recovery test is not practical on the production system, the project should use an isolated environment or controlled clone capable of demonstrating the complete restoration procedure.

Operational validation and proving

Operational validation confirms that the complete plant is fit for its intended use with real organizational roles, procedures and external dependencies.

A controlled proving period can play a role analogous to late-stage operational testing in software projects, but it must not be used to defer unresolved FAT or SAT failures. The proving period should begin only after:

• mandatory FAT and SAT tests have passed;
• safety-critical defects are closed;
• cybersecurity-critical defects are closed;
• the as-built configuration is baselined;
• operators are trained;
• support and escalation arrangements are active;
• logging, monitoring and backups are operational;
• open residual risks are formally accepted.

Operational proving should validate the following:

1. Real dispatch workflows. Confirm that actual operators can:

   • receive or generate schedules;
   • approve instructions;
   • dispatch the plant;
   • manage constraints;
   • observe execution;
   • respond to deviations.

2. Actual role allocation. Confirm that the responsibilities defined in the ConOps operate in practice, including:

   • Owner;
   • plant operator;
   • trader;
   • BRP/BSP or aggregator;
   • TSO/DSO interface personnel;
   • maintenance provider;
   • SOC/NOC;
   • OEM support.

3. Alarm and incident escalation. Confirm:

   • alarm receipt;
   • acknowledgement;
   • escalation;
   • on-call response;
   • incident classification;
   • Owner communication;
   • cybersecurity and operational coordination.

4. Remote maintenance governance. Validate:

   • request;
   • approval;
   • connection;
   • session supervision;
   • logging;
   • closure;
   • post-session review.

5. Market and external-service behaviour. Validate performance under realistic:

   • schedules;
   • data volumes;
   • latency;
   • temporary disconnection;
   • delayed data;
   • service interruption;
   • external-platform maintenance.

6. Monitoring and evidence. Confirm that:

   • logs remain complete;
   • timestamps are coherent;
   • alerts are actionable;
   • operator actions can be reconstructed;
   • command histories are retained;
   • configuration changes are controlled.

7. Configuration stability. Confirm that the plant can operate without:

   • recurring manual workarounds;
   • undocumented parameter changes;
   • broad temporary firewall rules;
   • shared commissioning accounts;
   • continuous vendor intervention;
   • unplanned service restarts.

8. Incident-response readiness. Exercise at least one representative scenario involving:

   • unauthorized access attempt;
   • loss of remote visibility;
   • suspicious command activity;
   • malware or endpoint-security alert;
   • loss of log forwarding;
   • isolation of a system or zone.

The proving period should have defined:

• duration;
• operating scenarios;
• performance thresholds;
• permitted interventions;
• defect-classification rules;
• evidence requirements;
• completion criteria.

Defects, deviations and re-testing

Testing is not complete when a defect is recorded. The project must determine how the defect affects the requirement, design baseline, other interfaces and previously executed tests. Defects should be classified by impact, for example:

• safety-critical;
• command- or grid-code-critical;
• cybersecurity-critical;
• operationally significant;
• recoverability-related;
• evidence-related;
• minor.

For every defect, define:

• affected requirement;
• observed result;
• root cause;
• affected systems and interfaces;
• corrective action;
• responsible party;
• target date;
• temporary control;
• residual risk;
• required re-test scope;
• acceptance authority.

A change made to correct one test failure may invalidate other results. Examples include:

• changing a firewall rule may require re-testing permitted and prohibited paths;
• changing EMS logic may require re-testing command validation and fallback;
• changing a certificate may require re-testing remote access and system authentication;
• changing a network route may require re-testing monitoring visibility and redundancy;
• changing a software version may require repeating configuration, interface and cybersecurity tests.

The accountable system integrator should perform an impact assessment before closing the defect. A deviation should not be used to convert a failed test into a pass. It is a separate governance decision documenting that a requirement has not been fully satisfied and defining the compensating controls, residual risk, duration and approval conditions.

FAT and SAT evidence package

The final evidence package should allow the Owner to reconstruct:

• what was tested;
• against which requirement;
• using which configuration;
• by whom;
• in which environment;
• with which result;
• which defects were found;
• how they were resolved;
• which residual risks remain.

The package should contain, at minimum:

• approved test plans and procedures;
• requirements-to-test traceability matrix;
• FAT readiness and exit records;
• SAT readiness and exit records;
• executed test records;
• witness signatures or approvals;
• logs and command traces;
• packet captures where relevant;
• screenshots and measurements;
• configuration exports;
• software and firmware inventories;
• certificate and account records where appropriate;
• defect and deviation register;
• re-test results;
• restore-test evidence;
• final as-built baseline;
• operational-proving report;
• formal acceptance decision.

Evidence should be retained in a controlled repository with:

• version control;
• access control;
• integrity protection;
• clear naming;
• retention requirements;
• Owner retrieval rights.

Acceptance criteria

FAT and SAT should be considered complete only when:

• all mandatory requirements have corresponding test evidence;
• the tested and as-built configurations are identified;
• critical positive and negative tests have passed;
• end-to-end command governance has been demonstrated;
• prohibited paths have been proven absent;
• failover and degraded modes have been demonstrated;
• representative restoration has succeeded;
• operational roles and escalation paths have been validated;
• unresolved defects and deviations are formally controlled;
• the Owner has received the required evidence;
• the accountable system integrator confirms that the plant is fit to proceed to the next lifecycle phase.

The objective is not to increase the number of test procedures. It is to transform FAT and SAT from equipment demonstrations into a structured verification and validation process capable of proving that the BESS plant is correctly integrated, secure, resilient, recoverable and fit for the Owner’s intended use.

Commissioning must verify the architecture, and procurement must make that possible

The validity of FAT, SAT and operational evidence depends on commissioning being performed against the approved final architecture. Commissioning should confirm that the installed plant conforms to:

• the approved system requirements;
• the functional and cybersecurity architecture;
• the interface-control records;
• the command-authority model;
• the network and conduit design;
• the configuration baseline;
• the recovery model;
• the approved FAT and SAT procedures.

It should expose deviations from that baseline. It should not become the phase in which missing architecture is created through emergency configuration.

Temporary commissioning arrangements are not the accepted architecture

Temporary arrangements may sometimes be required to install equipment, diagnose faults or execute specific tests. Typical examples include:

• broad firewall rules;
• temporary routes;
• shared commissioning accounts;
• disabled multifactor authentication;
• bypassed certificate validation;
• direct engineering access;
• temporary internet connectivity;
• vendor modems;
• unmanaged switches;
• disabled logging or monitoring;
• temporary connections between security zones.

These arrangements may facilitate an individual activity, but they cannot form part of the accepted plant merely because the corresponding test was completed successfully. Every temporary arrangement should be:

• explicitly identified;
• justified by a specific commissioning need;
• approved by the responsible technical and cybersecurity authorities;
• restricted to the minimum systems, protocols and duration required;
• logged and monitored where technically possible;
• assigned an expiry date or removal condition;
• removed before final testing;
• followed by re-testing against the intended production configuration.

A functional test performed while broad temporary access is active does not demonstrate that the approved restricted architecture works. The acceptance evidence must therefore show both:

1. that the temporary arrangement was removed; and
2. that the required function was successfully re-tested through the final architecture.

Commissioning discoveries must return to design control

When commissioning reveals an undocumented dependency or product limitation, the issue should not be normalized as a site workaround.

Examples include:

• an OEM requiring an undocumented internet tunnel;
• a BMS unable to produce the required logs;
• an EMS requiring additional undocumented ports;
• a cloud service proving necessary for normal plant operation;
• a TSO or DSO path permitting administrative access;
• a backup process that cannot restore the application;
• a product that does not support named accounts;
• inconsistent time synchronization across suppliers;
• an external platform capable of reaching field devices directly.

These are not merely commissioning issues. They are evidence of an incomplete requirement, architecture, interface, product selection or configuration baseline. The issue should be returned to the appropriate point in the assurance chain:

• Owner objective or operational scenario;
• system requirement;
• functional architecture;
• cybersecurity architecture;
• interface-control record;
• command-authority model;
• detailed configuration;
• FAT or SAT procedure;
• recovery design.

The corrective action should identify:

• the affected requirement;
• the root cause;
• the responsible party;
• the proposed design change;
• the operational and cybersecurity impact;
• the affected interfaces and configurations;
• the evidence invalidated by the change;
• the required re-test scope;
• any temporary compensating control;
• the residual risk and acceptance authority.

Updating the as-built drawing after an unapproved site change does not constitute change control. Documentation should record the result of an approved engineering decision, not retrospectively legitimize an uncontrolled implementation.

Procurement must make system assurance enforceable

Commissioning can verify only what the design has defined, and design can be enforced only where procurement has made the required responsibilities, information, artefacts, tests and evidence contractual. The contract should therefore identify:

• the party accountable for integrated-system behaviour;
• the authority of that party over supplier interfaces and configurations;
• the information each supplier and OEM must disclose;
• the required system-assurance and design artefacts;
• the configuration and change-control process;
• the required FAT, SAT, negative and recovery tests;
• the required acceptance evidence;
• the Owner’s rights to configurations, data, credentials, logs and project files;
• the treatment of defects, deviations and residual risks;
• the obligations continuing through handover, warranty and operation.

The contractual deliverables should include, at minimum:

• Concept of Operations;
• system and cybersecurity requirements;
• functional and cybersecurity architecture;
• command-authority model;
• interface-control register;
• responsibility matrix;
• asset, software and firmware inventories;
• data-flow and data-rights register;
• remote-access and external-service register;
• logging and monitoring matrix;
• backup and recovery design;
• configuration baseline;
• FAT/SAT traceability matrix;
• defect, deviation and residual-risk register;
• final as-built evidence package.

The contract should also require the principal Supplier or accountable integrator to flow the relevant obligations down to:

• battery OEMs;
• PCS suppliers;
• EMS and PPC suppliers;
• SCADA suppliers;
• RTU and telecontrol suppliers;
• telecommunications providers;
• cloud-service providers;
• remote-maintenance providers;
• cybersecurity suppliers;
• material subcontractors.

Supplier confidentiality may justify controlled handling of sensitive information. It should not prevent the Owner or accountable integrator from obtaining the information required to operate, secure, test, restore and investigate the plant.

Missing detail must remain an open obligation

Missing or incomplete information should not become implicitly accepted because the plant has been energized, a payment milestone has been reached or no immediate objection was raised. The following should remain open until formally provided, reviewed, tested and approved:

• undocumented interfaces;
• undefined command paths;
• incomplete signal lists;
• unknown ports or protocols;
• missing configuration exports;
• unavailable logs;
• undisclosed cloud dependencies;
• unresolved product limitations;
• missing restore procedures;
• temporary firewall rules or routes;
• commissioning accounts;
• unverified remote-access paths;
• incomplete FAT or SAT evidence.

A suitable contractual principle is:

Any omission, placeholder, unresolved interface, unavailable Supplier or OEM information, unverified product limitation, temporary commissioning configuration or incomplete evidence item shall remain an open Supplier obligation. It shall not be deemed accepted through document review, site installation, energization, testing, provisional operation, payment, passage of time or absence of an immediate Owner objection.

Similarly:

No departure from the approved requirements, architecture, interface model, configuration baseline or acceptance criteria shall be considered accepted unless it has been formally submitted, technically justified, risk-assessed, supported by appropriate compensating controls and approved in writing by the authorized Owner representative.

A deviation does not convert a failed requirement into a passed test. It records an explicit governance decision to accept a defined departure, together with its compensating controls, duration, residual risk and closure conditions.

Acceptance must remain linked to the final baseline

The project should distinguish among:

• design approval;
• FAT acceptance;
• release for shipment or installation;
• site-configuration acceptance;
• SAT acceptance;
• operational handover;
• provisional acceptance;
• final acceptance.

Each decision should be supported by evidence appropriate to that stage. In particular, final SAT and handover should not be completed until:

• the final as-built architecture is approved;
• temporary commissioning arrangements have been removed;
• operational accounts have replaced commissioning accounts;
• production certificates and credentials are active;
• firewall, routing and remote-access configurations reflect the approved design;
• logging and monitoring operate through the final paths;
• representative restoration has been demonstrated;
• final configurations and project files have been delivered;
• residual risks have named owners and formal acceptance;
• the Owner has received the complete acceptance dossier.

Energization, synchronization, first export, market registration or temporary commercial operation should not automatically constitute cybersecurity, integration or final contractual acceptance.

The practical relationship is therefore direct:

Commissioning verifies the architecture. Procurement creates the contractual conditions under which that architecture can be defined, implemented, tested and evidenced.

Without this bridge, commissioning personnel are forced to negotiate architecture at site. With it, they receive an approved baseline, controlled interfaces, named responsibilities, objective tests and enforceable evidence requirements.

The future BoP delivery model must include an accountable systems integrator

The traditional Balance of Plant role was primarily concerned with completing the physical plant around the principal equipment packages: civil works, electrical integration, auxiliary systems, cabling, communications infrastructure, grid connection and site commissioning.

That role is no longer sufficient for a modern BESS project. The value, safety, security and availability of the plant now depend on the coordinated behaviour of systems supplied by multiple organizations:

• battery containers and BMS;
• PCS and Power Island controllers;
• plant EMS and PPC;
• SCADA and HMI;
• RTU, telecontrol and grid-interface systems;
• protection and measurement systems;
• Owner, trader, BRP, BSP and aggregator platforms;
• remote-maintenance services;
• cloud and vendor platforms;
• telecommunications providers;
• cybersecurity, logging, monitoring and recovery systems.

The BoP contractor may still install much of the physical infrastructure, but the project cannot be accepted merely because those elements have been connected. Someone must demonstrate that the complete plant operates as one controlled system.

The future BoP contractor must therefore either assume the role of system integrator or work within an integration model in which that role is explicitly assigned to another party.

Three viable delivery models

There are three viable organizational models.

Model	Integration responsibility	Appropriate use	Principal risk
BoP-led integration	The BoP contractor acts as the accountable system integrator	The BoP contractor has strong control, automation, cybersecurity and testing capabilities	Responsibility may be claimed without sufficient technical authority or competence
BoP-led integration with specialist support	The BoP contractor subcontracts specialist integration activities but retains overall accountability	Specialist EMS, cybersecurity, telecom or verification expertise is required	Responsibility may become fragmented between the prime contractor and specialists
Owner-appointed independent integrator	The Owner appoints a separate system integrator, and all suppliers must comply with the integrated design	The Owner requires strong architectural independence or the BoP contractor cannot credibly integrate the complete system	Authority may be weak unless all supplier contracts require cooperation

The delivery model should be selected at procurement stage. It should not emerge informally during detailed design or commissioning. What is no longer acceptable is an implicit fourth model:

each supplier delivers its own subsystem, while integration responsibility is distributed among meetings, interface emails and commissioning personnel.

That model creates an unowned integration space.

The unowned integration space

An unowned integration space exists when:

• the battery OEM defines BMS behaviour;
• the PCS supplier defines inverter behaviour;
• the EMS supplier defines schedule and setpoint logic;
• the PPC supplier defines grid-control behaviour;
• the SCADA supplier defines operator interaction;
• the RTU supplier defines telecontrol signals;
• the trader or aggregator defines market interfaces;
• the telecom provider defines remote connectivity;
• the cybersecurity supplier installs firewalls, PAM, IDS or endpoint-security products;
• the BoP contractor connects the systems;
• no party owns the complete behavioural model.

Each supplier may be contractually compliant within its own scope. The integrated plant may nevertheless fail because the interfaces, priorities, assumptions and failure modes are inconsistent. Typical failures include:

• the EMS sends a command format that the PPC interprets differently;
• the PPC requests power outside the limits communicated by the BMS;
• the BMS updates charge limits more slowly than the control logic assumes;
• local and remote commands have undefined priority;
• the TSO command path bypasses the intended EMS validation;
• the Owner platform can transmit schedules but cannot confirm execution;
• the historian timestamps differ from control-system timestamps;
• the remote-access design conflicts with the OEM support model;
• the cybersecurity architecture blocks a required operational flow discovered only during SAT;
• a cloud service is required for normal operation despite the assumed local autonomy;
• no supplier is responsible for restoring the complete application chain after failure.

These are not isolated supplier defects. They are integration defects. A collection of individually compliant components does not create a compliant system.

Integration responsibility must be explicit

The accountable system integrator must be named contractually. The role should not be described through vague language such as:

• “coordination support”;
• “interface assistance”;
• “collaboration among suppliers”;
• “overall technical supervision”;
• “integration where applicable”.

The accountable integrator should be responsible for demonstrating that the complete plant satisfies the approved system requirements. This responsibility should include:

1. Requirements integration. Consolidate Owner, regulatory, grid-code, operational, cybersecurity, resilience and supplier requirements into a single controlled baseline.

2. Functional integration. Define how plant-level functions are distributed across BMS, PCS, EMS, PPC, SCADA, RTU, cloud and external platforms.

3. Interface integration. Control all material electrical, communication, software, data, command and organizational interfaces.

4. Command integration. Establish command sources, priorities, governance, validation, fallback and logging.

5. Cybersecurity integration. Ensure that zones, conduits, identities, remote access, monitoring, logging, backup and recovery support the required plant functions without creating bypasses.

6. Configuration integration. Maintain the approved versions, parameters, network settings, firewall rules, certificates, accounts and dependencies forming the tested baseline.

7. Verification and validation. Coordinate component FAT, subsystem FAT, site verification, integrated SAT, negative testing, recovery testing and operational proving.

8. Evidence integration. Assemble the traceability, configuration, test and handover evidence required for Owner acceptance.

The system integrator does not replace the technical responsibility of each supplier. It ensures that supplier responsibilities converge into a coherent plant.

Authority must accompany accountability

The integrator cannot be held responsible for system performance without the authority to control the conditions affecting that performance. The integration role should include the contractual right to:

• request complete technical information;
• obtain protocol and signal specifications;
• review equipment and software limitations;
• approve or reject interface designs;
• define common naming, timing and data conventions;
• review supplier configurations;
• require representative test environments;
• request configuration exports and logs;
• control changes affecting integrated behaviour;
• require corrective actions;
• require re-testing;
• prevent shipment or site implementation of non-conforming solutions;
• escalate unresolved risks to the Owner;
• recommend rejection of systems that cannot satisfy the approved requirements.

Supplier cooperation should be a contractual obligation, not a voluntary courtesy. Where a supplier claims that information is proprietary or confidential, the project should establish controlled access arrangements. Proprietary status should not prevent the integrator or Owner from receiving the information necessary to:

• operate the plant;
• validate the interface;
• assess cybersecurity;
• restore the system;
• investigate failures;
• verify regulatory or contractual compliance.

The capabilities the future BoP contractor must develop

A BoP contractor that assumes system-integration responsibility requires capabilities beyond conventional electrical and construction coordination. At minimum, it should demonstrate competence in the following areas.

• Systems engineering. The contractor should be able to:

  • develop and manage system requirements;
  • define a Concept of Operations;
  • construct functional architectures;
  • allocate functions to systems;
  • maintain requirement traceability;
  • manage verification and validation;
  • control deviations and residual risks.

  The contractor does not need to reproduce an aerospace process in full. It must, however, show a repeatable method for moving from Owner objectives to accepted plant behaviour.

• Control and automation integration. The contractor should understand:

  • BMS and PCS operating constraints;
  • EMS and PPC functions;
  • active- and reactive-power control;
  • grid-code control loops;
  • operating modes;
  • interlocks;
  • command priorities;
  • fallback states;
  • communication-loss behaviour.

  The integrator must be capable of challenging inconsistent supplier assumptions rather than merely forwarding interface documents.

• IT/OT architecture. The contractor should be able to design and review:

  • zones and trust domains;
  • VLANs and subnets;
  • routing;
  • firewall enforcement;
  • remote access;
  • management-plane separation;
  • logging;
  • backup;
  • time synchronization;
  • redundancy;
  • cloud and Owner interfaces.

  This capability must extend from architecture to detailed configuration and testing.

• Cybersecurity engineering. The contractor should understand how to translate cybersecurity requirements into:

  • system boundaries;
  • zones and conduits;
  • command-path restrictions;
  • identity and access controls;
  • PAM and remote-access workflows;
  • secure protocols;
  • logging and monitoring;
  • IDS/DPI coverage;
  • vulnerability and patch processes;
  • prohibited-path tests;
  • incident and recovery procedures.

  Cybersecurity competence cannot be demonstrated only by procuring security products.

• Interface and data engineering. The contractor should be able to control:

  • signal lists;
  • protocol mappings;
  • units and scaling;
  • timestamps;
  • quality indicators;
  • update rates;
  • read/write classification;
  • command semantics;
  • API behaviour;
  • data ownership;
  • buffering and synchronization;
  • failure and recovery behaviour.

  Interfaces must be treated as governed engineering objects rather than undocumented connections between supplier products.

• Test and evidence engineering. The contractor should be capable of:

  • deriving tests from requirements;
  • designing simulators and representative test environments;
  • coordinating multi-supplier FAT;
  • performing positive and negative tests;
  • collecting logs and packet evidence;
  • managing defects and re-tests;
  • comparing FAT and as-built baselines;
  • assembling a reproducible acceptance dossier.

  A contractor that cannot produce or control evidence cannot credibly act as the accountable integrator.

Minimum integration governance

The project should establish an Integration Management function led by the accountable integrator. This function should maintain a controlled set of registers and baselines.

Integration control	Purpose
System requirements baseline	Defines what the complete plant must achieve
Functional allocation matrix	Maps functions to systems and suppliers
Interface-control register	Defines all material system and organizational interfaces
Command-authority matrix	Defines command sources, priorities, validation and fallback
Responsibility matrix	Allocates design, implementation, testing and evidence obligations
Assumption register	Records assumptions requiring confirmation
Configuration baseline	Identifies the versions and settings forming the approved system
Integration risk register	Tracks risks arising from supplier boundaries and dependencies
Defect and deviation register	Controls failures, waivers, compensating controls and residual risks
Verification and validation matrix	Links requirements to FAT, SAT and operational tests
Acceptance-evidence index	Identifies the evidence supporting each accepted requirement

These records should be reviewed through formal integration gates rather than maintained only as administrative project files.

Required integration reviews

The integration process should include at least the following reviews:

• Operational concept review. Confirm that:

  • operating roles are defined;
  • market and grid interfaces are understood;
  • command authority is explicit;
  • degraded and emergency modes are identified;
  • remote operation and maintenance are governed.

• Requirements review. Confirm that:

  • requirements are complete and testable;
  • conflicting requirements are resolved;
  • responsibilities are allocated;
  • acceptance criteria are defined;
  • regulatory and grid-code assumptions are documented.

• Architecture review. Confirm that:

  • functions are allocated;
  • system boundaries are explicit;
  • interfaces are identified;
  • cybersecurity zones and conduits support the operational architecture;
  • resilience and recovery requirements are addressed.

• Interface freeze review. Confirm that each material interface has approved:

  • endpoints;
  • protocol;
  • signal or data list;
  • command semantics;
  • timing;
  • security controls;
  • failure behaviour;
  • logging;
  • test method.

• Configuration baseline review. Confirm that the system has a stable and testable baseline covering:

  • software;
  • firmware;
  • network configuration;
  • firewall rules;
  • accounts;
  • certificates;
  • application parameters;
  • backup;
  • logging;
  • time synchronization.

• FAT readiness review. Confirm that:

  • the relevant design is approved;
  • test environments are representative;
  • procedures are traceable;
  • expected evidence is defined;
  • known limitations are recorded;
  • supplier participation is confirmed.

• Site and SAT readiness review. Confirm that:

  • the installed plant matches the FAT baseline;
  • site changes are controlled;
  • temporary configurations are recorded;
  • final accounts, certificates and monitoring are active;
  • integrated tests can be executed against the intended architecture.

• Handover readiness review. Confirm that:

  • mandatory tests have passed;
  • defects and deviations are controlled;
  • configurations and project files are delivered;
  • recovery has been demonstrated;
  • operational roles are active;
  • the Owner has received the acceptance evidence.

Supplier responsibilities must remain intact

The existence of a system integrator must not allow subsystem suppliers to disclaim responsibility. Each supplier should remain responsible for:

• the correctness of its product;
• disclosed product limitations;
• compliance with interface requirements;
• accuracy of signal and protocol information;
• software and firmware support;
• vulnerability notification;
• configuration evidence;
• participation in FAT and SAT;
• correction of defects within its scope;
• provision of restore procedures and technical support;
• cooperation with incident investigation.

The integrator coordinates and validates the whole system. It does not absorb defects caused by incomplete or incorrect supplier deliverables. A suitable responsibility principle is:

Each Supplier remains fully responsible for the conformity, performance, security, documentation and support of its own scope. The accountable system integrator remains responsible for demonstrating the correct integration and end-to-end behaviour of the complete plant. Neither responsibility excludes or diminishes the other.

The Owner’s role cannot be passive

Even where the BoP contractor acts as system integrator, the Owner must retain architectural and acceptance authority. The Owner should:

• define the operational and commercial objectives;
• approve the ConOps;
• approve critical requirements;
• approve command authority;
• approve cybersecurity principles;
• approve material interfaces with Owner, market and external systems;
• review major architecture deviations;
• witness critical FAT and SAT tests;
• approve residual risks;
• retain access to configurations, data and evidence;
• control final acceptance.

The Owner should not replace the integrator by performing detailed supplier coordination informally. That recreates the same unowned integration problem under a different name. The Owner’s function is to govern objectives, approve risk and accept evidence. The integrator’s function is to deliver and demonstrate the integrated system.

When the BoP contractor should not be the integrator

The BoP contractor should not automatically receive the integration role merely because it holds the largest construction scope. The Owner should assess whether the contractor can demonstrate:

• relevant BESS integration experience;
• systems-engineering processes;
• control and automation competence;
• cybersecurity engineering capability;
• interface-management discipline;
• configuration-management tools;
• multi-supplier FAT experience;
• recovery and resilience testing experience;
• qualified personnel;
• independence from individual OEM solutions;
• authority over key subcontractors;
• willingness to provide complete Owner evidence.

Warning signs include:

• treating integration as the exchange of interface spreadsheets;
• relying on commissioning to resolve design questions;
• presenting product certificates as system assurance;
• refusing to define command authority;
• proposing broad routing for convenience;
• accepting undocumented vendor remote access;
• lacking a requirements-management process;
• lacking an interface-control process;
• lacking a formal configuration baseline;
• limiting FAT to supplier demonstrations;
• refusing negative cybersecurity tests;
• treating Owner data access as a commercial option.

Where these conditions exist, the Owner should appoint a separate integrator or strengthen its own integration function.

A maturity model for BoP integration capability

The BoP contractor’s integration maturity can be assessed using the following model.

Level	Characteristics	Project consequence
Level 1 — Equipment coordination	Coordinates drawings, deliveries and basic signal interfaces	Insufficient for complex BESS integration
Level 2 — Technical interface management	Maintains interface lists and coordinates supplier testing	Useful but still dependent on late integration
Level 3 — Controlled system integration	Manages requirements, architecture, interfaces, configuration and integrated FAT/SAT	Minimum credible level for accountable BESS integration
Level 4 — Evidence-based system assurance	Adds cybersecurity, resilience, negative testing, recovery validation and full traceability	Appropriate target for high-value, market-facing BESS
Level 5 — Lifecycle integration	Extends assurance through operations, updates, incidents, obsolescence and repowering	Target for portfolios and long-term Owner operating models

The contract should require evidence of the claimed maturity rather than relying on generic statements of experience. Relevant evidence may include:

• sample system-assurance plans;
• requirements and traceability tools;
• interface-control registers;
• configuration-management procedures;
• FAT/SAT matrices;
• cybersecurity architectures;
• recovery-test evidence;
• defect and deviation processes;
• qualifications of proposed personnel;
• references from comparable integrated projects.

Integration performance must be measurable

The integrator’s performance should be assessed using metrics tied to system outcomes rather than document volume. Useful indicators include:

• percentage of approved system requirements with allocated owners;
• percentage of material interfaces with approved interface records;
• number of unresolved interface assumptions;
• number of design issues discovered for the first time during SAT;
• percentage of FAT/SAT tests directly traceable to requirements;
• number of temporary commissioning routes, accounts and firewall rules;
• percentage of as-built configurations matching the approved baseline;
• number of critical prohibited-path test failures;
• percentage of critical systems with demonstrated restoration;
• number of open high-risk deviations at handover;
• percentage of acceptance evidence delivered and approved;
• time required to identify responsibility for an integration defect.

The objective is not to optimize a numerical score. It is to reveal whether integration is being managed early or deferred to site. A project in which major interface decisions, command priorities and security exceptions continue to emerge during SAT has failed its integration process, even if the final test programme is eventually completed.

The future BoP delivery model

The future BoP contractor must evolve from a coordinator of physical packages into an integrator of cyber-physical behaviour. That evolution requires the contractor to manage more than equipment boundaries. It must manage:

• functional dependencies;
• control authority;
• software and firmware baselines;
• data and command semantics;
• cybersecurity boundaries;
• external services;
• operational roles;
• degraded modes;
• recovery;
• evidence.

The contractor does not need to manufacture every subsystem or develop every application. It must ensure that all supplied elements form a coherent, testable and supportable plant. Where the BoP contractor cannot perform this role, the Owner must assign it elsewhere.

What is no longer sustainable is leaving integration to emerge from supplier negotiations and site workarounds. The decisive requirement is simple:

one accountable party must own the integrated behavioural model, possess the authority to control the interfaces, and provide the evidence that the complete BESS plant is fit for the Owner’s intended use.

Without that role, the project delivers components. With it, the project can deliver a system.

A practical gated delivery model

The previous sections establish three principles:

1. the BESS must be designed as an integrated cyber-physical system rather than as a collection of equipment packages;
2. one accountable party must govern system integration;
3. acceptance must be based on traceable evidence linking Owner objectives, requirements, architecture, configuration, testing and operational use.

A gated delivery model converts those principles into project control. The gates are not additional administrative milestones placed beside the engineering process. They are decision points at which the project demonstrates that the information required for the next phase is sufficiently complete, coherent and controlled.

Each gate should answer four questions:

• Is the design mature enough to proceed?
• Are responsibilities and interfaces sufficiently defined?
• Are the risks and deviations visible and owned?
• Will proceeding preserve the validity of the assurance chain?

The purpose is to prevent unresolved decisions from being transferred downstream. Without gates, incomplete requirements are transferred into architecture, incomplete architecture into detailed design, incomplete interfaces into FAT, and unresolved FAT issues into site commissioning. The project may still progress physically, but integration debt accumulates until it emerges during SAT or operation.

A gated model establishes controlled progression and explicit feedback:

%%{init: {"theme": "neo", "look": "handDrawn", "layout": "elk"}}%%
flowchart TD
    G1["Gate 1<br/>Owner objectives<br/>and ConOps"]
    G2["Gate 2<br/>Requirements<br/>baseline"]
    G3["Gate 3<br/>Functional and<br/>cybersecurity architecture"]
    G4["Gate 4<br/>Detailed design<br/>and interface freeze"]
    G5["Gate 5<br/>FAT readiness"]
    G6["Gate 6<br/>FAT acceptance"]
    G7["Gate 7<br/>Site implementation<br/>and configuration audit"]
    G8["Gate 8<br/>Integrated SAT"]
    G9["Gate 9<br/>Operational handover"]
    G10["Gate 10<br/>Continuous<br/>assurance"]

    G1 --> G2 --> G3 --> G4 --> G5 --> G6 --> G7 --> G8 --> G9 --> G10

    D["Defects, deviations,<br/>changes and residual risks"]

    G5 --> D
    G6 --> D
    G7 --> D
    G8 --> D
    G10 --> D

    D -. requirement impact .-> G2
    D -. architecture impact .-> G3
    D -. design impact .-> G4
    D -. re-test .-> G5

Figure 4: A gated BESS delivery process from Owner objectives to continuous lifecycle assurance.

The process is sequential, but not strictly linear. A defect discovered during FAT may require a change to the detailed design, architecture or requirement baseline. A site deviation may invalidate part of the FAT evidence. An operational incident may require a new requirement, architecture change and regression test.

The correct response is therefore to return to the affected gate. Progress should not be preserved by weakening the requirement or changing the test result after the fact.

Gate governance

Each gate should have:

• a defined purpose;
• mandatory inputs;
• required deliverables;
• entry criteria;
• review participants;
• decision authority;
• objective exit criteria;
• a controlled record of the decision.

The possible gate decisions should be limited to:

Decision	Meaning
Pass	All mandatory criteria are satisfied and the project may proceed
Conditional pass	The project may proceed subject to explicitly defined, low-risk and time-bounded actions
Hold	The project may not proceed until specified issues are resolved
Reject / redesign	The proposed solution does not satisfy the approved requirements and must be revised

A conditional pass should identify:

• the open item;
• affected requirement;
• responsible party;
• corrective action;
• due date;
• risk classification;
• compensating control;
• evidence required for closure;
• condition beyond which the project may not proceed.

A gate should not be passed merely because the schedule requires progression.

Gate 1 — Owner objectives and Concept of Operations

Gate 1 establishes why the plant is being built and how it is intended to operate. The purpose is to prevent the technical solution from being defined before the Owner’s commercial, operational, cybersecurity, resilience and data objectives are explicit.

Mandatory inputs

The gate should consider:

• investment and revenue model;
• expected market participation;
• grid-connection and dispatching context;
• Owner operating model;
• intended suppliers and service providers;
• availability and performance objectives;
• cybersecurity and resilience expectations;
• data and evidence requirements;
• anticipated asset lifetime.

Required decisions

The Owner should define and approve:

1. Commercial objectives. Including:

   • energy arbitrage;
   • balancing services;
   • capacity obligations;
   • grid-support services;
   • portfolio optimization;
   • expected availability and performance.

2. Operating roles. Define the roles of:

   • Owner;
   • plant operator;
   • trader;
   • BRP;
   • BSP;
   • aggregator;
   • TSO or DSO;
   • maintenance provider;
   • OEMs;
   • remote SOC/NOC;
   • cloud providers.

3. Market participation. Define:

   • relevant markets and services;
   • scheduling and nomination responsibilities;
   • required data exchange;
   • availability and constraint communication;
   • operational time horizons.

4. Command authority. Define:

   • who may issue plant instructions;
   • who approves them;
   • where they are validated;
   • the priority among Owner, market, TSO/DSO, local and safety commands;
   • emergency and fallback authority.

5. Grid interfaces. Define:

   • TSO/DSO communication;
   • telecontrol;
   • measurement;
   • dispatch-order handling;
   • grid-code functions;
   • external operational dependencies.

6. Cybersecurity targets. Define:

   • target security posture;
   • remote-access principles;
   • command-path restrictions;
   • logging and monitoring expectations;
   • supplier and cloud constraints;
   • Owner audit and evidence rights.

7. Availability and recovery objectives. Define:

   • required availability;
   • maximum tolerable outages;
   • RTO and RPO expectations;
   • degraded operating modes;
   • external-service dependency limits.

8. Evidence and data rights. Define:

   • Owner access to plant data;
   • log and evidence ownership;
   • data export requirements;
   • cloud exit rights;
   • lifecycle and battery-passport information;
   • retention requirements.

Required outputs

Gate 1 should produce:

• approved Concept of Operations;
• actor and role matrix;
• operating-mode catalogue;
• command-priority principles;
• commercial and market-use-case register;
• initial system boundary;
• preliminary regulatory applicability register;
• high-level cybersecurity and resilience objectives;
• data and evidence principles.

Exit criteria

Gate 1 should pass only when:

• the intended use is sufficiently defined;
• operational actors are identified;
• command authority is not ambiguous;
• critical external interfaces are known;
• Owner data and evidence rights are explicit;
• the main degraded and emergency scenarios are identified;
• unresolved business decisions are recorded with named owners.

The output should be stable enough to support requirements development. It need not contain detailed technical design.

Gate 2 — Requirements baseline

Gate 2 converts the approved ConOps and Owner objectives into clear, numbered and testable requirements. The purpose is to establish the baseline against which architecture, implementation and acceptance will be judged.

Requirements to be approved

The baseline should include:

1. System and operational requirements. Cover:

   • plant functions;
   • operating modes;
   • command behaviour;
   • performance;
   • market integration;
   • availability;
   • degraded operation.

2. Grid-code and external-interface requirements. Cover:

   • telecontrol;
   • measurement;
   • response times;
   • active- and reactive-power control;
   • TSO/DSO obligations;
   • communication loss;
   • evidence of compliance.

3. Cybersecurity requirements. Cover:

   • zones and conduits;
   • access control;
   • remote access;
   • command-path protection;
   • logging;
   • monitoring;
   • vulnerability management;
   • backup and recovery;
   • cloud and supplier security.

4. Safety and physical-security requirements. Cover:

   • emergency actions;
   • protection priorities;
   • fire and gas detection;
   • physical access;
   • intrusion detection;
   • anti-tamper controls;
   • interaction between safety and control systems.

5. Resilience and recovery requirements. Cover:

   • redundancy;
   • failover;
   • RTO/RPO;
   • telecom diversity;
   • trusted recovery baselines;
   • degraded operation;
   • recovery testing.

6. Data, evidence and lifecycle requirements. Cover:

   • Owner data access;
   • data export;
   • log retention;
   • configuration evidence;
   • software and firmware inventories;
   • battery-passport data;
   • support periods;
   • end-of-support notifications;
   • handover obligations.

Responsibility allocation

Each requirement should identify:

• accountable party;
• implementing supplier;
• affected system or interface;
• verification method;
• expected acceptance phase;
• required evidence.

A requirement without an owner is not ready for approval.

Regulatory assumptions

The gate should document:

• applicable EU and national requirements;
• grid-code assumptions;
• entity- and asset-scope assumptions;
• forthcoming requirements considered during design;
• contractual interpretation where applicability is conditional.

The project should distinguish:

• legally mandatory requirements;
• grid or market obligations;
• contractual requirements;
• Owner design requirements;
• selected standards and good practice.

Required outputs

Gate 2 should produce:

• approved system requirements specification;
• approved cybersecurity requirements specification;
• regulatory and grid-code applicability matrix;
• requirement-allocation matrix;
• preliminary requirements-to-test matrix;
• approved acceptance criteria;
• open-assumption register;
• responsibility matrix.

Exit criteria

Gate 2 should pass only when:

• requirements are uniquely identified;
• requirements are sufficiently clear and testable;
• conflicts have been resolved or explicitly escalated;
• each material requirement has an accountable party;
• verification methods are defined at least at a high level;
• requirements do not depend on undocumented Supplier assumptions;
• open items are classified and controlled.

Gate 3 — Functional, control, cybersecurity and resilience architecture

Gate 3 defines how the complete plant will satisfy the approved requirements. The purpose is to establish the integrated behavioural model before detailed products and configurations are frozen.

Architecture scope

The gate should approve the following:

1. Functional architecture. Define:

   • EMS functions;
   • PPC functions;
   • SCADA and HMI functions;
   • BMS and PCS functions;
   • telecontrol;
   • data integration;
   • logging;
   • monitoring;
   • backup;
   • time synchronization.

2. Function allocation. Map each function to:

   • system;
   • product or subsystem;
   • responsible supplier;
   • responsible operator;
   • redundancy role;
   • relevant interfaces.

3. Command architecture. Define:

   • command sources;
   • command-governance point;
   • command priority;
   • validation;
   • fallback;
   • emergency behaviour;
   • command logging.

4. Cybersecurity architecture. Define:

   • system boundary;
   • zones and sub-zones;
   • trust domains;
   • conduits;
   • prohibited paths;
   • management plane;
   • remote-access model;
   • logging and monitoring;
   • Owner and cloud interfaces.

5. Resilience architecture. Define:

   • redundancy;
   • single points of failure;
   • failover;
   • external dependencies;
   • telecom diversity;
   • degraded modes;
   • recovery priorities.

6. External-service architecture. Define:

   • Owner platforms;
   • market and aggregator platforms;
   • TSO/DSO systems;
   • remote service;
   • cloud and vendor systems;
   • SOC/NOC;
   • data and command capabilities.

Architecture reviews

The gate should challenge whether:

• products are being used to define functions rather than implement them;
• command authority is inferred from connectivity;
• any external system bypasses the intended command-governance point;
• required operational flows conflict with the zone model;
• the design depends on cloud or vendor services during degraded operation;
• cybersecurity controls create operational single points of failure;
• recovery dependencies are understood.

Required outputs

Gate 3 should produce:

• approved functional architecture;
• function-allocation matrix;
• command-authority model;
• cybersecurity zone and conduit architecture;
• prohibited-path baseline;
• resilience and redundancy architecture;
• external-service architecture;
• high-level data-flow model;
• architecture decision register.

Exit criteria

Gate 3 should pass only when:

• all material functions are allocated;
• system and trust boundaries are explicit;
• command sources and priority are defined;
• material interfaces are identified;
• cybersecurity zoning supports plant operation;
• failure and degraded modes are described;
• responsibilities are consistent with the architecture;
• no critical integration issue is intentionally deferred to commissioning.

Gate 4 — Detailed design and interface freeze

Gate 4 transforms the approved architecture into an implementable and testable technical baseline. The purpose is to eliminate ambiguity at supplier boundaries before equipment configuration and integrated testing.

Detailed design to be approved

The gate should approve:

1. Network design. Including:

   • VLANs;
   • subnets;
   • gateways;
   • routes;
   • firewall zones;
   • redundant paths;
   • management networks;
   • external links.

2. Interface-control records. For each interface:

   • endpoints;
   • initiator;
   • protocol;
   • port;
   • signal or data list;
   • read/write and command capability;
   • authentication;
   • encryption;
   • timing;
   • failure behaviour;
   • logging;
   • test method.

3. Firewall and conduit design. Define:

   • exact permitted flows;
   • default-deny policy;
   • endpoint-specific allow-listing;
   • prohibited flows;
   • failover behaviour;
   • rule ownership;
   • rule-review process.

4. Identity and account model. Define:

   • users;
   • roles;
   • service accounts;
   • MFA;
   • PAM;
   • local emergency accounts;
   • credential ownership;
   • revocation and review.

5. Certificate and key architecture. Define:

   • certificate authorities;
   • certificate issuance;
   • trust stores;
   • key ownership;
   • renewal;
   • expiry monitoring;
   • recovery.

6. Signal and command semantics. Define:

   • values;
   • units;
   • scaling;
   • quality;
   • timestamps;
   • update rates;
   • command acknowledgement;
   • rejection codes;
   • duplicate and replay handling.

7. Logging and monitoring design. Define:

   • log sources;
   • event categories;
   • destinations;
   • buffering;
   • retention;
   • SIEM forwarding;
   • IDS/DPI visibility;
   • alert escalation.

8. Backup and recovery design. Define:

   • backup scope;
   • repositories;
   • access controls;
   • immutability or deletion protection;
   • trusted baselines;
   • restore sequence;
   • test method.

9. Time-synchronization hierarchy. Define:

   • authoritative time sources;
   • NTP/PTP roles;
   • client/server relationships;
   • redundancy;
   • loss-of-time behaviour;
   • monitoring.

Interface freeze

Interface freeze means that material interface properties cannot be changed without formal impact assessment. It does not mean that no correction is possible. It means that any change must identify:

• affected requirements;
• affected systems;
• cybersecurity impact;
• timing and performance impact;
• test impact;
• required document updates;
• required re-testing.

Required outputs

Gate 4 should produce:

• approved detailed network design;
• final interface-control register;
• approved signal and protocol lists;
• command-path matrix;
• firewall and conduit rule design;
• account and credential design;
• certificate and key plan;
• logging and SIEM matrix;
• time-synchronization design;
• backup and recovery design;
• detailed configuration requirements;
• detailed FAT/SAT traceability matrix.

Exit criteria

Gate 4 should pass only when:

• all critical interfaces have approved records;
• no material signal or command semantics remain undefined;
• routes and firewall flows can be derived from the design;
• accounts and remote-access paths are defined;
• log, backup and time requirements are allocated;
• open product limitations are documented;
• the design can be translated into a controlled configuration baseline;
• unresolved issues do not threaten FAT validity.

Gate 5 — FAT readiness review

Gate 5 determines whether the system is ready to produce valid factory-acceptance evidence. The purpose is to prevent testing of unstable, incomplete or undocumented configurations.

FAT readiness criteria

FAT should not begin until:

1. The design is approved. The relevant:

   • requirements;
   • architecture;
   • interface records;
   • command model;
   • cybersecurity design;
   • recovery design

   should be approved or formally controlled.

2. Configurations are baselined. The project should identify:

   • hardware revisions;
   • software and firmware versions;
   • application parameters;
   • network settings;
   • firewall rules;
   • accounts;
   • certificates;
   • logging;
   • backup settings;
   • time sources.

3. Test procedures are approved. Procedures should define:

   • requirement references;
   • preconditions;
   • test environment;
   • sequence;
   • expected result;
   • evidence;
   • witnesses;
   • defect handling.

4. Test facilities are adequate. Confirm availability of:

   • actual equipment;
   • simulators;
   • protocol emulators;
   • hardware-in-the-loop systems;
   • representative switches and firewalls;
   • realistic latency or communication conditions;
   • log collection.

5. Evidence collection is active. Confirm that:

   • logs;
   • packet captures;
   • screenshots;
   • measurements;
   • configuration exports;
   • command traces

   can be retained in a controlled repository.

6. Open items are classified. Each open item should be classified as:

   • non-blocking;
   • test limitation;
   • design defect;
   • product limitation;
   • approved deviation;
   • FAT blocker.

Required outputs

Gate 5 should produce:

• FAT readiness report;
• approved test procedures;
• frozen FAT configuration baseline;
• test-environment description;
• witness schedule;
• open-item and deviation list;
• evidence-management plan;
• formal authorization to begin FAT.

Exit criteria

Gate 5 should pass only when the FAT results will be reproducible, traceable and relevant to the system intended for installation.

Gate 6 — FAT execution and acceptance

Gate 6 verifies the component, subsystem, interface, cybersecurity, resilience and recovery properties that can be demonstrated before site installation.

FAT scope

The programme should include:

1. Component verification. Verify:

   • product identity;
   • firmware and software;
   • configuration;
   • access controls;
   • protocols;
   • logs;
   • backup/export;
   • failover;
   • hardening;
   • limitations.

2. Subsystem integration. Verify:

   • BMS–PCS interaction;
   • EMS/PPC–Power Island interaction;
   • SCADA–EMS interaction;
   • grid-interface exchange;
   • Owner and market interfaces;
   • security-service integration;
   • alarm and event correlation.

3. Command testing. Verify:

   • valid command execution;
   • command priority;
   • constraint validation;
   • acknowledgement;
   • logging;
   • fallback.

4. Cybersecurity positive testing. Verify:

   • authorized access;
   • PAM;
   • MFA;
   • secure protocols;
   • logging;
   • SIEM forwarding;
   • IDS/DPI visibility;
   • backup paths.

5. Cybersecurity negative testing. Demonstrate rejection of:

   • unauthorized commands;
   • stale or replayed commands;
   • unauthorized access;
   • direct field-device paths;
   • telemetry-to-command misuse;
   • management-plane bypass;
   • unintended cloud or TSO/DSO access;
   • prohibited lateral movement.

6. Failover and recovery testing. Verify:

   • redundant component behaviour;
   • communication loss;
   • service restart;
   • configuration restoration;
   • representative backup restoration;
   • alarm generation.

FAT defects

Every failed test should identify:

• affected requirement;
• root cause;
• corrective action;
• affected baseline;
• required re-test;
• responsibility;
• residual risk.

A design change made during FAT should be reflected in:

• requirements where necessary;
• architecture;
• interface records;
• configuration baseline;
• test procedures;
• site implementation instructions.

Required outputs

Gate 6 should produce:

• executed FAT records;
• component and subsystem reports;
• positive and negative security evidence;
• command traces;
• final FAT configuration exports;
• software and firmware inventory;
• defect and deviation register;
• re-test evidence;
• FAT acceptance decision;
• controlled list of actions required before SAT.

Exit criteria

Gate 6 should pass only when:

• mandatory tests have been completed;
• critical failures are closed;
• approved deviations are explicit;
• the tested configuration is retained;
• FAT evidence is complete;
• the released configuration is suitable for site installation.

Gate 7 — Site implementation and configuration audit

Gate 7 verifies that the physical plant matches the architecture and baseline accepted at FAT. The purpose is to prevent unrecorded site changes from invalidating the factory evidence.

Site implementation verification

The project should verify:

1. Asset conformity. Confirm:

   • manufacturer;
   • model;
   • serial number;
   • hardware revision;
   • software and firmware;
   • licences;
   • location.

2. Network conformity. Confirm:

   • VLANs;
   • subnets;
   • routes;
   • gateways;
   • firewall zones;
   • firewall rules;
   • switch ports;
   • trunks;
   • redundant paths.

3. Security configuration. Confirm:

   • accounts;
   • roles;
   • MFA;
   • PAM paths;
   • certificates;
   • log forwarding;
   • IDS/DPI visibility;
   • endpoint protection;
   • remote access.

4. Infrastructure services. Confirm:

   • time sources;
   • backup destinations;
   • monitoring;
   • virtualization;
   • storage;
   • power and environmental dependencies.

5. Physical installation. Confirm:

   • rack placement;
   • cabling;
   • labelling;
   • redundant power;
   • fibre routing;
   • tamper protection;
   • physical separation.

Configuration audit

The as-built system should be compared with the FAT baseline using:

• configuration exports;
• checksums;
• automated comparison where available;
• manual inspection;
• approved change records.

Each delta should be classified as:

• approved site change;
• documentation correction;
• unapproved deviation;
• product substitution;
• temporary commissioning arrangement;
• defect.

Temporary arrangements

Temporary:

• routes;
• firewall rules;
• accounts;
• modems;
• internet connections;
• disabled controls;
• direct engineering paths

should be recorded, time-bounded and removed before final SAT testing.

Required outputs

Gate 7 should produce:

• as-installed asset inventory;
• FAT-to-site comparison report;
• configuration-audit report;
• approved site-change register;
• temporary-arrangement register;
• updated as-built design;
• SAT readiness recommendation.

Exit criteria

Gate 7 should pass only when the project can demonstrate that SAT will be executed against the intended final architecture rather than an uncontrolled commissioning configuration.

Gate 8 — Integrated SAT and operational validation

Gate 8 verifies and validates the complete as-built plant in its actual technical and operational environment. The purpose is to demonstrate end-to-end fitness, not merely completion of local supplier commissioning.

Integrated SAT scope

The programme should include:

1. End-to-end telemetry. Verify:

   • field-to-SCADA;
   • field-to-EMS/PPC;
   • historian;
   • Owner platform;
   • market platform;
   • TSO/DSO;
   • SOC/SIEM.

2. End-to-end command paths. Verify:

   • command origin;
   • authentication;
   • validation;
   • allocation;
   • execution;
   • acknowledgement;
   • resulting plant response;
   • logging.

3. Operating modes. Test:

   • charge;
   • discharge;
   • standby;
   • grid support;
   • balancing service;
   • local operation;
   • remote operation;
   • maintenance;
   • emergency;
   • degraded communication;
   • recovery.

4. Grid and market integration. Verify:

   • schedules;
   • availability;
   • constraints;
   • telecontrol;
   • active- and reactive-power behaviour;
   • response times;
   • partial unavailability.

5. Cybersecurity controls. Verify:

   • production identities;
   • real PAM workflows;
   • session recording;
   • final firewall rules;
   • prohibited paths;
   • log forwarding;
   • IDS/DPI;
   • security alarms;
   • access expiry and revocation.

6. Resilience and recovery. Test:

   • server failure;
   • network failure;
   • firewall failover;
   • telecom loss;
   • time-source loss;
   • external-platform loss;
   • isolation of a compromised zone;
   • restoration from backup.

7. Operational validation. Confirm that real actors can execute the processes defined in the ConOps, including:

   • dispatch;
   • alarm management;
   • remote maintenance;
   • incident escalation;
   • market communication;
   • constraint management;
   • recovery.

Operational proving

Where appropriate, a controlled proving period should validate:

• realistic schedules;
• actual operating roles;
• realistic latency and data volumes;
• on-call response;
• remote-service governance;
• logging continuity;
• configuration stability;
• absence of recurring workarounds.

The proving period should not be used to postpone unresolved mandatory SAT tests.

Required outputs

Gate 8 should produce:

• executed SAT report;
• requirements-to-test completion matrix;
• command and telemetry evidence;
• prohibited-path evidence;
• failover and recovery evidence;
• operational-proving report;
• updated defect and deviation register;
• final as-built configuration baseline;
• SAT acceptance decision.

Exit criteria

Gate 8 should pass only when:

• end-to-end behaviour has been demonstrated;
• critical positive and negative tests have passed;
• the final architecture has been tested;
• representative recovery has succeeded;
• operational roles have been validated;
• temporary arrangements have been removed;
• residual risks are formally controlled;
• the Owner has received the required evidence.

Gate 9 — Operational handover

Gate 9 transfers control from the project delivery organization to the Owner and operational service organizations. The purpose is to ensure that the Owner receives not only a functioning plant, but also the information, authority, access, tools and evidence required to operate and govern it.

Required handover package

The Supplier and system integrator should deliver:

1. As-built architecture. Including:

   • functional architecture;
   • network architecture;
   • zones and conduits;
   • external services;
   • command paths;
   • management paths;
   • recovery architecture.

2. Final configurations. Including:

   • servers;
   • applications;
   • PLCs and controllers;
   • firewalls;
   • switches;
   • PAM;
   • logging;
   • backup;
   • time synchronization;
   • monitoring.

3. Project and source files. Including, where applicable:

   • PLC projects;
   • SCADA projects;
   • EMS/PPC configurations;
   • HMI projects;
   • database schemas;
   • scripts;
   • automation files;
   • recovery media.

4. Credentials, certificates and keys. Deliver through controlled mechanisms:

   • Owner administrative accounts;
   • operational accounts;
   • emergency accounts;
   • certificates;
   • private keys where Owner ownership is required;
   • renewal instructions;
   • trust-store information.

5. Backup and recovery package. Including:

   • trusted baselines;
   • backup jobs;
   • repository configuration;
   • restore procedures;
   • recovery dependencies;
   • restore-test evidence;
   • RTO/RPO register.

6. Inventories. Including:

   • hardware;
   • software;
   • firmware;
   • licences;
   • cloud services;
   • certificates;
   • support periods;
   • end-of-support dates;
   • subcontractors and service providers.

7. Cybersecurity and operational evidence. Including:

   • FAT/SAT records;
   • logs;
   • command traces;
   • prohibited-path tests;
   • session records;
   • configuration exports;
   • vulnerability status;
   • residual risks.

8. Operational procedures. Including:

   • normal operation;
   • degraded operation;
   • alarm escalation;
   • remote access;
   • incident response;
   • backup;
   • recovery;
   • change management;
   • vulnerability and patch handling.

9. Support and escalation model. Define:

   • support contacts;
   • service hours;
   • severity levels;
   • escalation times;
   • OEM involvement;
   • remote-access rules;
   • incident support;
   • warranty processes.

Knowledge transfer

Handover should include training for:

• operators;
• Owner administrators;
• cybersecurity personnel;
• maintenance personnel;
• incident-response personnel;
• backup and recovery personnel.

Training should cover actual as-built systems and procedures rather than generic product demonstrations.

Required outputs

Gate 9 should produce:

• signed handover checklist;
• final acceptance dossier;
• evidence index;
• credential-delivery record;
• training records;
• final residual-risk register;
• support and escalation register;
• Owner acceptance decision.

Exit criteria

Gate 9 should pass only when the Owner can independently:

• monitor the plant;
• operate authorized functions;
• control access;
• retrieve data;
• inspect logs;
• manage credentials;
• perform or invoke recovery;
• investigate incidents;
• govern suppliers;
• maintain the accepted baseline.

A plant is not operationally handed over while the Owner remains dependent on undocumented Supplier knowledge or inaccessible Supplier-controlled systems.

Gate 10 — Continuous assurance

Gate 10 extends system assurance into operation. The accepted plant is not static. Software, firmware, vulnerabilities, certificates, suppliers, cloud platforms, market interfaces, regulations and operating practices will change throughout its lifecycle.

The purpose of continuous assurance is to preserve the validity of the accepted system baseline while allowing controlled evolution.

Continuous activities

The Owner and service providers should manage the following:

1. Vulnerability management. Monitor:

   • CVEs;
   • supplier advisories;
   • actively exploited vulnerabilities;
   • product-security notices;
   • end-of-support risks;
   • newly discovered architectural exposure.

2. Patch and update management. Control:

   • assessment;
   • compatibility testing;
   • approval;
   • deployment;
   • rollback;
   • evidence;
   • compensating controls.

3. Supplier and cloud-service changes. Assess:

   • service architecture changes;
   • endpoint changes;
   • subcontractor changes;
   • data-location changes;
   • API changes;
   • authentication changes;
   • new command capabilities;
   • service termination.

4. Certificate and credential lifecycle. Manage:

   • renewal;
   • revocation;
   • expiry;
   • trust-store changes;
   • access reviews;
   • dormant accounts;
   • role changes;
   • emergency credentials.

5. Configuration management. Maintain:

   • current baselines;
   • approved changes;
   • configuration backups;
   • drift detection;
   • asset inventories;
   • software and firmware inventories.

6. Access governance. Perform:

   • periodic account reviews;
   • privileged-access reviews;
   • remote-access reviews;
   • supplier-access revocation;
   • session-record reviews;
   • role recertification.

7. Incident readiness. Conduct:

   • incident exercises;
   • communication tests;
   • evidence-preservation drills;
   • isolation procedures;
   • Owner/Supplier coordination;
   • regulatory-reporting preparation.

8. Backup and recovery assurance. Perform:

   • backup monitoring;
   • repository-integrity checks;
   • configuration restore tests;
   • application restore tests;
   • periodic recovery exercises;
   • RTO/RPO review.

9. Market and grid-interface evolution. Assess:

   • new market services;
   • BRP/BSP or aggregator changes;
   • TSO/DSO rule changes;
   • new command types;
   • new schedules;
   • new communication requirements;
   • changed response obligations.

10. Regulatory change. Monitor:

• cybersecurity legislation;
• grid-code updates;
• product-security obligations;
• battery-passport requirements;
• data and cloud obligations;
• critical-infrastructure requirements.

Change assurance

Any material change should re-enter the assurance process at the appropriate gate. Examples include:

Change	Minimum gate re-entry
New market interface	Gate 1 or 2, followed by architecture and interface review
New command source	Gate 2 and Gate 3
Firewall or routing change	Gate 4
Software or firmware upgrade	Gate 4 or Gate 5, depending on impact
New cloud provider	Gate 2 or Gate 3
Replacement EMS/PPC	Gate 2 through Gate 8
Change to TSO/DSO requirements	Gate 2
New remote-maintenance provider	Gate 3 or Gate 4
Major recovery-architecture change	Gate 3 or Gate 4
Critical cyber incident	Relevant gates determined by root-cause analysis

The change should be assessed for:

• requirement impact;
• architecture impact;
• interface impact;
• cybersecurity impact;
• recovery impact;
• test impact;
• evidence updates;
• training requirements;
• residual risk.

Continuous assurance outputs

Gate 10 should maintain:

• current requirements baseline;
• current architecture;
• current configuration baseline;
• current asset and software inventory;
• vulnerability and patch register;
• access-review records;
• supplier and cloud-service register;
• certificate register;
• incident and exercise records;
• restore-test evidence;
• approved change register;
• current residual-risk register.

Gate metrics and management visibility

The gated process should be measurable. Useful indicators include:

• percentage of requirements approved and allocated;
• percentage of interfaces with approved control records;
• number of unresolved architecture assumptions;
• number of design changes introduced during FAT;
• number of material issues first discovered during SAT;
• percentage of tests traceable to requirements;
• number of temporary commissioning configurations;
• percentage of as-built configurations matching the FAT baseline;
• number of critical negative-test failures;
• percentage of critical systems with demonstrated restoration;
• number of open high-risk deviations at handover;
• percentage of required evidence accepted by the Owner.

These indicators should not be used as substitutes for engineering judgment. They should reveal where integration debt is accumulating. A project with many drawings completed but unresolved interfaces, unallocated requirements and untested recovery is not mature.

The value of the gated model

The gated model changes the project’s default behaviour. Under a conventional delivery sequence:

• ambiguity moves downstream;
• suppliers optimize local scopes;
• integration occurs late;
• temporary solutions become permanent;
• commissioning absorbs design failures;
• the Owner receives evidence after decisions have already been made.

Under the gated system-assurance model:

• Owner objectives drive requirements;
• requirements drive architecture;
• architecture drives interfaces and configuration;
• configuration drives FAT;
• FAT establishes the site baseline;
• SAT validates the as-built plant;
• handover transfers authority and evidence;
• continuous assurance preserves the accepted system.

The value is not that every gate prevents all defects. The value is that defects are discovered while the project still has the information, authority, contractual leverage and time required to correct them. The gated model therefore provides a practical path from fragmented EPC delivery to an integrated BESS plant that is operationally fit, secure, resilient, recoverable and supportable throughout its lifecycle.

This is not more bureaucracy: it is earlier and more controllable engineering

The most common objection to a stronger system-assurance model is that it introduces additional documents, reviews, tests and project cost. That objection focuses on the visible cost of structured engineering while ignoring the less visible cost of unresolved integration risk.

Requirements workshops, architecture reviews, interface-control records, configuration baselines and formal FAT/SAT procedures consume time and resources. Their cost is identifiable because it appears in the project plan. The alternative does not eliminate that cost. It defers it.

When requirements, interfaces, command priorities, cybersecurity controls and recovery arrangements are not resolved during design, the project pays later through:

• redesign;
• repeated supplier coordination;
• additional site visits;
• commissioning delays;
• emergency configuration changes;
• duplicated testing;
• contractual disputes;
• delayed market entry;
• operational instability;
• cybersecurity remediation;
• long-term dependence on suppliers.

The relevant comparison is therefore not:

more design versus less design.

It is:

controlled early engineering versus expensive late discovery.

Cost is committed before it is visibly spent

Systems-engineering guidance consistently emphasizes that early architectural decisions determine a substantial proportion of lifecycle cost, even though relatively little money may have been spent when those decisions are made.²⁹

This distinction between cost spent and cost committed is essential for BESS projects. A design decision may appear inexpensive when approved, but it can determine future costs for:

• software licensing;
• telecom services;
• cloud dependency;
• cybersecurity products;
• data access;
• remote support;
• system redundancy;
• backup architecture;
• spare parts;
• patching;
• certificate management;
• operational staffing;
• restoration;
• technology replacement.

For example, accepting a vendor-dependent cloud architecture may initially reduce local infrastructure cost. It may simultaneously commit the Owner to:

• recurring service charges;
• constrained data access;
• vendor-controlled updates;
• proprietary APIs;
• long-term remote connectivity;
• difficult service migration;
• reduced ability to operate after supplier failure.

Similarly, accepting a flat network or broad routing model may reduce detailed design effort. It can later commit the project to:

• firewall redesign;
• new switching infrastructure;
• service interruption;
• additional FAT/SAT;
• plant shutdowns;
• regulatory remediation;
• greater incident impact.

The financial consequence of an architectural choice should therefore be assessed across the plant lifecycle, not only against the immediate EPC budget.

The visible cost of stronger engineering

The stronger approach requires explicit investment in activities such as:

1. Owner and stakeholder workshops. Used to define:

   • intended market participation;
   • operating roles;
   • command authority;
   • availability expectations;
   • cybersecurity targets;
   • data rights;
   • recovery objectives.

2. Requirements engineering. Used to convert business, operational, regulatory and technical objectives into controlled and testable statements.

3. Architecture development. Used to define:

   • system functions;
   • function allocation;
   • interfaces;
   • trust boundaries;
   • command paths;
   • degraded modes;
   • recovery dependencies.

4. Supplier interface management. Used to resolve inconsistent assumptions among battery, PCS, EMS/PPC, SCADA, telecom, grid-interface, cloud and cybersecurity suppliers.

5. Configuration management. Used to establish the approved software, firmware, network, account, certificate and application baseline.

6. Verification and validation planning. Used to derive FAT, SAT, negative cybersecurity tests, recovery tests and operational scenarios from the requirements.

7. Evidence production. Used to retain:

   • configurations;
   • logs;
   • command traces;
   • test results;
   • restoration evidence;
   • deviations;
   • residual-risk decisions.

These costs should be estimated and budgeted as engineering and assurance work rather than treated as incidental commissioning support.

The hidden cost of weak integration

The weaker approach creates costs that are delayed, fragmented across contracts and difficult to forecast.

Design and commissioning cost

Typical consequences include:

• discovering undocumented interfaces after equipment delivery;
• repeating FAT because supplier assumptions were inconsistent;
• introducing broad temporary firewall rules;
• reconfiguring VLANs and routes at site;
• creating accounts and access workflows during commissioning;
• repeating SAT after late software changes;
• extending specialist and OEM presence at site;
• delaying energization or commercial operation.

Commercial cost

Potential consequences include:

• delayed market onboarding;
• inability to provide contracted balancing services;
• inaccurate availability or state-of-charge information;
• failure to execute schedules;
• performance penalties;
• missed market opportunities;
• prolonged reliance on manual operation.

Operational cost

Potential consequences include:

• recurring operator workarounds;
• excessive false alarms;
• unclear escalation responsibilities;
• dependence on individual technicians;
• inability to diagnose failures remotely;
• repeated service interruption;
• unstable configurations;
• preventable plant derating.

Cybersecurity cost

Potential consequences include:

• retrofit of zoning and firewall controls;
• removal of undocumented vendor access;
• replacement of unsupported equipment;
• implementation of logging after commissioning;
• emergency patching;
• incident investigation without complete evidence;
• regulatory corrective actions;
• increased insurance or audit exposure.

Recovery cost

Potential consequences include:

• backups that cannot restore applications;
• missing engineering project files;
• unavailable licences or certificates;
• inability to rebuild virtual machines;
• reliance on OEM personnel for basic restoration;
• extended outages after cyber or equipment failure.

Supplier and contractual cost

Potential consequences include:

• disputes over interface ownership;
• disputes over whether a limitation was disclosed;
• disputes over responsibility for failed integrated behaviour;
• variation orders for work that should have been included;
• prolonged warranty discussions;
• difficulties enforcing corrective action after payment or energization.

These costs are often larger than the cost of structured early engineering because they occur when:

• equipment has already been purchased;
• construction is advanced;
• contractual leverage is reduced;
• schedule pressure is high;
• specialist resources are scarce;
• operational revenue is at risk.

The cost of change increases downstream

The same issue can be represented across the delivery lifecycle:

Project phase	Typical correction	Relative disruption
Owner objectives and ConOps	Clarify role, operating scenario or business requirement	Low
Requirements	Revise or add a system requirement	Low
Architecture	Change function allocation, boundary or command path	Moderate
Detailed design	Change interfaces, routing, accounts or protocols	Moderate
FAT	Reconfigure products and repeat tests	High
Site installation	Replace equipment, recable or redesign network implementation	Very high
SAT	Rework integrated architecture and repeat end-to-end tests	Very high
Operation	Shut down, retrofit, migrate services or accept prolonged risk	Potentially critical

The exact cost multiplier varies by project, but the direction is consistent: the later a system-level defect is discovered, the more parties, equipment, evidence and contractual commitments it affects. This is why the gated delivery model should treat unresolved design questions as blockers rather than allowing them to migrate downstream.

System assurance should be proportionate

A stronger delivery model should not generate documentation for its own sake. The level of formality should be proportionate to:

• plant capacity and investment value;
• market role;
• grid criticality;
• number of command sources;
• complexity of the EMS/PPC architecture;
• number of external and cloud services;
• remote-access model;
• supplier fragmentation;
• cybersecurity exposure;
• recovery requirements;
• portfolio standardization objectives.

A smaller plant with a simple local operating model may require fewer artefacts and reviews than a large market-facing BESS participating in multiple balancing services. The underlying controls, however, remain the same:

• define the intended use;
• establish accountable integration;
• control material interfaces;
• preserve configuration traceability;
• test end-to-end behaviour;
• test prohibited behaviour;
• demonstrate recovery;
• retain evidence.

Proportionality should reduce unnecessary detail. It should not remove the assurance chain.

How to prevent assurance from becoming bureaucracy

The project should apply the following rules:

1. Every artefact must support a decision or test. A document should exist because it:

   • defines a requirement;
   • controls an interface;
   • establishes a baseline;
   • allocates responsibility;
   • supports verification;
   • preserves evidence.

   Documents without a defined lifecycle purpose should not be produced.

2. Information should have one authoritative source. The project should avoid maintaining conflicting copies of:

   • asset inventories;
   • IP plans;
   • signal lists;
   • interface records;
   • software versions;
   • firewall rules;
   • test status.

   Where possible, structured registers should generate or support multiple project views.

3. Reviews should be decision-oriented. Each review should identify:

   • decisions required;
   • responsible approvers;
   • blocking issues;
   • accepted assumptions;
   • actions and due dates.

   A meeting without decision authority or controlled outputs is coordination, not governance.

4. Traceability should be maintained progressively. Requirements should be linked to architecture and tests as the design evolves. Reconstructing traceability shortly before acceptance produces administrative evidence rather than engineering control.

5. Testing should maximize reusable evidence. Logs, packet captures, configuration exports and command traces should be captured in a form that supports:

   • test acceptance;
   • future audits;
   • incident investigation;
   • regression testing;
   • lifecycle change.

6. Supplier information should be standardized. Common templates should be used for:

   • interfaces;
   • assets;
   • software;
   • vulnerabilities;
   • accounts;
   • configurations;
   • FAT/SAT records;
   • deviations.

   This reduces interpretation effort and exposes missing information early.

7. Gate criteria should be stable. Suppliers should know before execution:

   • what must be delivered;
   • how it will be assessed;
   • what evidence is required;
   • what prevents progression.

The objective is not to add layers of approval. It is to replace informal, repeated and inconsistent decision-making with controlled engineering decisions made once at the appropriate stage.

The business case for the Owner

The stronger approach protects more than cybersecurity compliance. It protects the Owner’s ability to:

• enter the market on schedule;
• change trader, aggregator or service provider;
• operate without permanent OEM dependence;
• recover after failure;
• investigate incidents;
• obtain plant data;
• maintain configurations;
• manage warranties;
• repower or extend the plant;
• demonstrate due diligence to investors, lenders, insurers and authorities.

It also improves portfolio scalability. Without a common system-assurance model, every plant develops:

• different interfaces;
• different remote-access arrangements;
• different naming;
• different evidence;
• different backup methods;
• different operating procedures;
• different cybersecurity exceptions.

That diversity increases long-term operating cost and makes portfolio-level monitoring, incident response and service-provider changes more difficult. A common gated process and standard architecture allow the Owner to create reusable:

• requirements;
• zone and conduit models;
• interface templates;
• command patterns;
• cybersecurity controls;
• FAT/SAT tests;
• evidence structures;
• operating procedures.

The investment in system assurance therefore creates value beyond a single project.

How management should evaluate the additional effort

Senior management should not ask only:

How much additional engineering does the assurance model require?

It should also ask:

• Which risks are being retired earlier?
• Which supplier assumptions are being made explicit?
• Which commissioning activities will be avoided?
• Which operational dependencies are being reduced?
• Which evidence will the Owner possess at handover?
• Which future supplier changes will become easier?
• Which outages can be shortened through tested recovery?
• Which regulatory and contractual risks will become demonstrable and governable?

A practical management review can use the following comparison:

Management question	Weak delivery indicator	Strong assurance indicator
Are Owner objectives testable?	Objectives remain in presentations and contracts	Objectives are translated into approved requirements
Is integration owned?	Responsibility is distributed among suppliers	One accountable integrator has authority and obligations
Are interfaces controlled?	Signal spreadsheets and emails	Approved interface-control records
Is cybersecurity designed?	Security-product bill of materials	Zones, conduits, access, command and monitoring architecture
Is recovery credible?	Successful backup jobs	Demonstrated restore within defined objectives
Is SAT meaningful?	Equipment demonstrations and broad temporary access	End-to-end positive and negative tests against final configuration
Can the Owner operate independently?	Continued reliance on undocumented supplier knowledge	Complete handover of configurations, credentials, procedures and evidence
Is lifecycle change governable?	Ad hoc supplier updates	Controlled configuration and regression testing

The economic case for system assurance is strongest when the project recognizes that the plant must remain operable, secure and adaptable long after the EPC team has left.

Conclusion

The traditional EPC documentation model is no longer sufficient for European BESS projects. Electrical, civil and mechanical engineering remain fundamental. Single-line diagrams, protection schemes, cable schedules, rack layouts, equipment specifications and installation procedures remain necessary.

They describe only part of the system. A modern BESS is simultaneously:

• an electrical installation;
• a battery and power-conversion system;
• an industrial automation system;
• a software-dependent control platform;
• a remotely operated asset;
• a market-participating resource;
• a TSO- or DSO-connected control resource;
• a data-generating connected-product environment;
• a cybersecurity-sensitive supply chain;
• a regulated cyber-physical infrastructure asset.

Its commercial value emerges from coordinated operation. Its risk emerges from the same coordination. The plant must receive schedules and commands, respect battery and grid constraints, exchange data with external parties, support remote maintenance, retain evidence, survive failure, recover from compromise and evolve throughout a long operational life. Those properties cannot be established through equipment conformity alone.

The required evolution

The practical evolution is from equipment-centred EPC delivery to evidence-based system assurance. That evolution requires the project to change its starting point.

Instead of beginning with equipment packages and supplier drawings, it should begin with:

• Owner objectives;
• intended operating scenarios;
• market roles;
• grid interfaces;
• command authority;
• cybersecurity and resilience targets;
• data and evidence rights;
• lifecycle expectations.

Those objectives must then be transformed into:

• testable requirements;
• functional architecture;
• command architecture;
• cybersecurity architecture;
• controlled interfaces;
• configuration baselines;
• FAT and SAT procedures;
• operational acceptance evidence.

The assurance chain must remain intact from initial objectives to lifecycle operation.

The central organizational change

The integrated plant must have an accountable system integrator. That party may be:

• the BoP contractor;
• the EPC contractor;
• a specialist integrator;
• the Owner’s engineering organization.

The specific model can vary. What cannot vary is the existence of one party with both:

• responsibility for integrated behaviour; and
• authority to control requirements, interfaces, configurations, testing and evidence.

Without that role, integration remains distributed among suppliers and is eventually delegated to commissioning personnel.

The central technical change

Architecture must precede configuration. The project must define before implementation:

• which function is authoritative;
• where commands enter;
• how commands are validated;
• which systems may communicate;
• which paths must not exist;
• how users and suppliers obtain access;
• where logs are generated;
• how time is synchronized;
• how systems fail;
• how systems recover.

Cybersecurity must be designed as part of plant operation rather than added as an external layer. A firewall, PAM platform, IDS sensor, SIEM connector or backup product contributes to assurance only when it implements a defined architectural requirement and passes the corresponding tests.

The central verification change

FAT and SAT must become verification and validation phases. They must demonstrate not only that required functions work, but also that:

• unauthorized commands are rejected;
• unsafe values are constrained;
• command priorities are respected;
• remote access follows the approved path;
• telemetry cannot become an unintended command path;
• external systems cannot reach field devices directly;
• logs can reconstruct events;
• failures produce defined degraded states;
• critical systems can be restored;
• the as-built plant matches the accepted baseline.

Commissioning must verify the architecture rather than invent it through emergency configuration.

The central contractual change

Procurement must make system assurance enforceable. The contract must define:

• system-integration responsibility;
• required design artefacts;
• supplier information obligations;
• interface-control requirements;
• FAT/SAT evidence;
• configuration handover;
• data and credential rights;
• change and deviation governance;
• recovery obligations;
• lifecycle support.

Missing information must remain an open obligation. Energization, temporary operation, payment or passage of time must not convert undocumented paths, unresolved interfaces or incomplete evidence into implied acceptance.

The central lifecycle change

Acceptance is not the end of assurance. The plant will change through:

• software and firmware updates;
• new vulnerabilities;
• certificate renewal;
• supplier changes;
• cloud-service changes;
• new market services;
• new grid requirements;
• operating-model changes;
• repowering and augmentation.

Each material change must re-enter the assurance process at the appropriate point. The objective is to preserve the logic connecting:

Owner need → requirement → architecture → configuration → test → evidence → accepted operation.

The better way to build BESS plants

The stronger model does not eliminate defects, supplier limitations or project change. It changes when and how they are discovered.

It exposes integration problems while:

• design authority still exists;
• contractual leverage remains available;
• suppliers can still correct their products;
• equipment has not yet been irreversibly installed;
• test evidence can still be generated efficiently;
• operational revenue is not yet at risk.

This is why the stronger approach is not unnecessary bureaucracy. It is a mechanism for moving cost, risk and decision-making to the stage where they can be controlled. A BESS project delivered through this model is not merely constructed and energized. It is:

• operationally defined;
• contractually allocated;
• architecturally integrated;
• securely configured;
• systematically verified;
• operationally validated;
• demonstrably recoverable;
• evidenced for acceptance;
• prepared for lifecycle change.

That is the delivery model required for a BESS plant whose value depends on digital operation and whose failure can affect the Owner, market participants, grid operators and the wider electricity system.

The future of BESS construction is therefore not the abandonment of EPC engineering. It is its completion through system assurance.

See also cybersecurity longforms

Controllo e Monitoraggio della Rete: la Nuova Postura di Sicurezza degli Impianti Connessi

Gli aggiornamenti Terna agli Allegati A.13, A.69 e A.52 nel quadro europeo di resilienza cyber, NIS2, CRA e Perimetro di Sicurezza Nazionale Cibernetica

Measuring Cyber Risk in the Italian Corporate Sector

A Banca d’Italia indicator of cybersecurity vulnerability designed to support creditworthiness evaluation

The December 2025 Cyberattack on Poland’s Energy Sector

A detailed reconstruction of the incident, the malware, and the wider significance for energy and OT security

See also energy longforms

Controllo e Monitoraggio della Rete: la Nuova Postura di Sicurezza degli Impianti Connessi

Gli aggiornamenti Terna agli Allegati A.13, A.69 e A.52 nel quadro europeo di resilienza cyber, NIS2, CRA e Perimetro di Sicurezza Nazionale Cibernetica

The December 2025 Cyberattack on Poland’s Energy Sector

A detailed reconstruction of the incident, the malware, and the wider significance for energy and OT security

See also posts

When Digital Trust Gets a Deadline

The U.S. 2030 post-quantum cryptography order, enterprise cryptographic debt, and why a federal mandate matters beyond America

When Vulnerability Databases Become Triage Systems

NIST’s NVD update, record CVE growth, and the economics of AI-scaled cyberattacks

Quantum Cryptography at the Edge of Feasibility: Resource Estimates, Architectural Divergence, and Systemic Risk

An analysis of the Google and Oratomic results on Shor’s resource estimates and their implications for the convergence of quantum circuit optimization, error correction, and hardware architectures

Quantum Computing Threats and the Advantage of Acting Now

Why trust expires before systems fail, and how early remediation becomes a strategic program rather than an emergency rewrite

Quantum Key Distribution and Post-Quantum Cryptography

Concepts, roles, and correct use

Cybersecurity in an Era with Quantum Computers: Interpreting Mosca’s Risk Inequality

Why $x$ plus $y$ greater than $z$ turns quantum readiness into a present day governance problem

Footnotes

1. The expression “European electricity-market framework” refers primarily to European Union. Regulation (EU) 2019/943 of the European Parliament and of the Council of 5 June 2019 on the internal market for electricity (recast). Official Journal of the European Union. URL; and European Union. Directive (EU) 2019/944 of the European Parliament and of the Council of 5 June 2019 on common rules for the internal market for electricity and amending Directive 2012/27/EU (recast). Official Journal of the European Union. URL. The framework was revised by European Union. Regulation (EU) 2024/1747 amending Regulations (EU) 2019/942 and (EU) 2019/943 as regards improving the Union’s electricity market design. Official Journal of the European Union. URL; and European Union. Directive (EU) 2024/1711 amending Directives (EU) 2018/2001 and (EU) 2019/944 as regards improving the Union’s electricity market design. Official Journal of the European Union. URL.

2. Balance Responsible Party (BRP) and Balancing Service Provider (BSP) are harmonized roles used throughout the European electricity market. Under Commission Regulation (EU) 2017/2195, a BRP is a market participant, or its chosen representative, responsible for its imbalances, while a BSP is a market participant whose reserve-providing units or groups can provide balancing services to a transmission system operator. ENTSO-E uses the same roles in its Harmonised Electricity Market Role Model. National market rules may retain translated or legacy terminology, but BRP and BSP are the appropriate Europe-wide acronyms. European Union. Commission Regulation (EU) 2017/2195 establishing a guideline on electricity balancing, Article 2. EUR-Lex. URL. ENTSO-E. The Harmonised Electricity Market Role Model. European Network of Transmission System Operators for Electricity. URL

3. The expression “European electricity-market framework” refers primarily to European Union. Regulation (EU) 2019/943 of the European Parliament and of the Council of 5 June 2019 on the internal market for electricity (recast). Official Journal of the European Union. URL; and European Union. Directive (EU) 2019/944 of the European Parliament and of the Council of 5 June 2019 on common rules for the internal market for electricity and amending Directive 2012/27/EU (recast). Official Journal of the European Union. URL. The framework was revised by European Union. Regulation (EU) 2024/1747 amending Regulations (EU) 2019/942 and (EU) 2019/943 as regards improving the Union’s electricity market design. Official Journal of the European Union. URL; and European Union. Directive (EU) 2024/1711 amending Directives (EU) 2018/2001 and (EU) 2019/944 as regards improving the Union’s electricity market design. Official Journal of the European Union. URL.

4. European Commission. NIS2 Directive: securing network and information systems. Shaping Europe’s Digital Future. URL

5. European Union. Commission Delegated Regulation (EU) 2024/1366 establishing a network code on sector-specific rules for cybersecurity aspects of cross-border electricity flows. EUR-Lex. URL

6. European Union. Directive (EU) 2022/2557 on the resilience of critical entities. EUR-Lex. URL

7. European Commission. Cyber Resilience Act. Shaping Europe’s Digital Future. Reporting obligations apply from 11 September 2026; the main obligations apply from 11 December 2027. URL

8. European Union. Regulation (EU) 2023/2854 on harmonised rules on fair access to and use of data. EUR-Lex. The Regulation applies from 12 September 2025. URL

9. European Union. Regulation (EU) 2023/1542 concerning batteries and waste batteries, Article 77 and Annex XIII. Official Journal of the European Union. From 18 February 2027, Article 77 requires a battery passport for each light means of transport battery, electric-vehicle battery and industrial battery with a capacity greater than 2 kWh placed on the market or put into service. URL. European Commission. Batteries. Internal Market, Industry, Entrepreneurship and SMEs. URL. BatteryPass. Battery Pass. BatteryPass Consortium. BatteryPass provides non-binding technical and implementation guidance and is not the legal basis for the obligation or a regulatory certification scheme. URL

10. European Union. Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence. EUR-Lex. The Act classifies AI used as a safety component in the supply of electricity as potentially high risk. URL

11. Italian Republic. Legislative Decree 4 September 2024, No. 138, implementing Directive (EU) 2022/2555. Gazzetta Ufficiale. See Article 25 for the 24-hour, 72-hour and one-month incident-reporting sequence. URL

12. Agenzia per la Cybersicurezza Nazionale. Perimetro di Sicurezza Nazionale Cibernetica — FAQ. URL

13. Terna. Codice di Rete Italiano. Terna. URL. Terna. Aggiornamento Codice di Rete — 14 maggio 2026. Terna. The update includes Annex A.13, “Criteri di connessione al sistema di controllo di Terna.” URL. See also (Italian): Montano A. (2026). Controllo e Monitoraggio della Rete: la Nuova Postura di Sicurezza degli Impianti Connessi. Author’s blog. URL

14. Bundesamt für Sicherheit in der Informationstechnik. About NIS-2. Germany’s NIS2 Implementation Act entered into force on 6 December 2025. URL

15. Bundesnetzagentur. IT-Sicherheitskatalog für Energieanlagen. Existing catalogues remain applicable pending publication of the revised catalogue; existing attack-detection systems remain required. URL

16. Bundesnetzagentur. IT-Sicherheitskatalog für Digitale Energiedienste. Operators of digital energy services have been regulated by Bundesnetzagentur since 6 December 2025. URL

17. European Commission. Commission refers Ireland, Spain, France and the Netherlands to the Court of Justice for failing to transpose NIS2. 8 July 2026. URL

18. French Republic. Arrêté du 29 mai 2019 fixant les règles de sécurité et les modalités de déclaration des systèmes d’information d’importance vitale. Légifrance. URL

19. ANSSI. Référentiel Cyber France — ReCyF, version 2.5. 17 March 2026. URL

20. Government of the Netherlands. Cyberbeveiligingswet and Wet weerbaarheid kritieke entiteiten effective from 15 August 2026. 7 July 2026. URL

21. Centre for Cybersecurity Belgium. Belgium sets the standard: first Member State to fully implement NIS2. 18 October 2024. URL

22. Centre for Cybersecurity Belgium. The NIS2 Law. The guidance explains the obligation to manage cybersecurity risks in the direct supply chain. URL

23. Centre for Cybersecurity Belgium. NIS2: 18 April 2026 deadline — What essential entities must have in place. URL

24. Ofgem. NIS Guidance for Downstream Gas and Electricity Operators of Essential Services in Great Britain, version 3.0. January 2026. URL

25. UK National Cyber Security Centre. Cyber Assessment Framework. URL

26. UK Department for Energy Security and Net Zero. Energy Sector Cyber Security Strategy. 28 May 2026. URL

27. International Organization for Standardization. ISO/IEC/IEEE 15288:2023 — Systems and software engineering — System life cycle processes. ISO. URL. National Aeronautics and Space Administration. NASA Systems Engineering Handbook, Revision 2. NASA. URL. DNV. Integrated Software Dependent Systems class notation. DNV. These references provide established methods for lifecycle control, requirements traceability, interface management, system integration, verification and validation. They are methodological references rather than generally applicable legal obligations for BESS projects. URL

28. International Electrotechnical Commission. IEC 62443-3-2:2020 — Security for industrial automation and control systems — Part 3-2: Security risk assessment for system design. IEC. The standard addresses definition of the system under consideration, cybersecurity risk assessment, and partitioning into zones and conduits. URL. International Electrotechnical Commission. IEC 62443-3-3:2013 — Industrial communication networks — Network and system security — Part 3-3: System security requirements and security levels. IEC. URL

29. National Aeronautics and Space Administration. NASA Systems Engineering Handbook, Revision 2. The handbook distinguishes verification from validation and explains why lifecycle cost and risk are strongly influenced by early design decisions. URL