Who controls the data: governance and triage

Ofgem's Data Best Practice Guidance (DBP) is the overarching framework for data governance in the GB energy sector. The current text is the Data Best Practice Guidance and Supporting Information (2026), which supersedes v3.5 of 30 June 2025; it builds on the earlier versions and sets the principles that licensed energy companies are expected to follow. DBP is not an industry code in the same way as the BSC or SEC, but it is licence-backed for relevant network companies and is assessed through regulatory reporting and price-control processes.

The presumed open principle

The most important principle in the DBP is “presumed open”. This means that all energy data should be published openly unless there is a specific reason not to. The burden of proof falls on the organisation holding the data to justify restricting access, not on the party requesting it. This is a deliberate inversion of the traditional default, which was to restrict data unless there was a reason to share it.

The presumed open principle does not mean that all data is published. Three categories of data may legitimately be restricted: personal data (protected by UK GDPR), commercially sensitive data (which could distort markets if disclosed), and security-sensitive data (which could create safety or cyber risks if made public). The Data Triage Playbook provides the structured process for determining which category applies.

The Data Triage Playbook: four steps

The Data Triage Playbook is a decision framework for classifying datasets. It consists of four sequential questions, each of which must be answered before proceeding to the next:

1. Is it personal data? If the dataset contains information relating to an identified or identifiable natural person (UK GDPR), it cannot be published openly without anonymisation or aggregation that demonstrably prevents re-identification.
2. Is it commercially sensitive? If publication would give a market participant an unfair advantage or reveal proprietary information (hedging positions, contract prices, forecasting algorithms), it may require restriction. Aggregate market data is generally not commercially sensitive even if it derives from sensitive inputs.
3. Is it security-sensitive? If the dataset could identify vulnerabilities in critical national infrastructure or enable cyber or physical attacks (e.g., SCADA configurations, substation vulnerability assessments), it requires restriction based on material risk, not theoretical risk.
4. Default to open. If the dataset passes all three tests - not personal, not commercially sensitive, not security-sensitive - it should be published openly. This includes network capacity data, aggregated demand profiles, and most operational planning data.

Five sensitivity levels

The DBP defines five sensitivity levels that refine the triage outcome:

Level 0, Open. Freely available to anyone without registration or conditions. Published on the organisation's website or a public data portal. Examples: Long-Term Development Statements, aggregated demand data, published network capacity maps.

Level 1, Shared (registered access). Available to anyone who registers and agrees to terms of use. No detailed vetting, but the organisation knows who has accessed the data. Examples: detailed network topology data, substation loading time series, granular weather data.

Level 2, Shared (vetted access). Available to organisations that have been assessed and approved. Access requires a data sharing agreement. Examples: individual meter point data used for network planning (pseudonymised), detailed asset condition data.

Level 3, Restricted. Available only to named individuals within approved organisations, with specific access controls and audit trails. Examples: customer personal data, commercially sensitive contract data.

Level 4, Closed. Not shared outside the holding organisation except under legal compulsion. Examples: active cybersecurity vulnerability data, ongoing investigation data, information subject to legal privilege.

The FAIR principles originated in scientific data management but have been adopted by Ofgem as a standard for energy data governance. FAIR stands for Findable, Accessible, Interoperable, and Reusable. Each principle addresses a different dimension of data usability.

Findable

Data must be easy to discover. This requires persistent identifiers (every dataset has a unique, stable identifier that does not change over time), rich metadata (descriptions, keywords, dates, ownership, and update frequency), and registration in searchable catalogues. In the energy sector, findability is a major weakness. Many DNOs publish data on their websites, but there is no single catalogue of all published energy data. Finding a specific dataset often requires knowing which organisation holds it and navigating their specific data portal.

Accessible

Data must be retrievable through standardised protocols. This means using common data access methods (HTTPS, APIs, standard download formats), providing clear access conditions (who can access it and what steps are required), and ensuring the access mechanism is reliable and maintained. Accessibility also requires that metadata remains accessible even if the data itself has been removed or restricted.

Interoperable

Data must use shared vocabularies, formats, and standards so it can be combined with other datasets. In the energy sector, interoperability is undermined by the code fragmentation described in Module 7. The BSC, REC, SEC, and UNC each define their own data models with different field names, formats, and validation rules for overlapping concepts. The Common Information Model (CIM, covered in Module 13) is the international standard that could solve this, but adoption in GB is still partial.

Reusable

Data must have clear usage licences and provenance information. Users need to know what they are allowed to do with the data (commercial use, redistribution, derivative works), where the data came from (provenance), and how reliable it is (quality metrics). In the energy sector, many datasets are published without clear licences, which creates legal uncertainty for third parties who want to build products and services on top of the data.

Dublin Core metadata

The DBP recommends using Dublin Core as the metadata standard for energy datasets. Dublin Core is a simple, widely adopted standard that defines 15 core metadata elements: Title, Creator, Subject, Description, Publisher, Contributor, Date, Type, Format, Identifier, Source, Language, Relation, Coverage, and Rights. Each published energy dataset should include these elements at minimum, enabling consistent cataloguing and discovery.

DNO publishing decision process

When a DNO decides whether to publish a dataset, the recommended process combines the triage playbook with FAIR assessment. First, the dataset is triaged to determine its sensitivity level. If it can be shared, the DNO applies FAIR principles to determine the best format, metadata requirements, and access mechanism. The dataset is then published through the DNO's data portal with Dublin Core metadata, a clear licence, and a contact point for data users. Quality metrics (completeness, accuracy, timeliness) should be published alongside the data itself.

The five-level maturity model introduced in Module 7 provides a useful lens for assessing governance reality versus aspiration. When Ofgem assessed DNO data governance maturity as part of RIIO-ED2, the results were sobering. Most DNOs self-assessed at Level 2 (Developing) or low Level 3 (Defined). None credibly claimed Level 4 (Managed) across all data domains. Level 5 (Optimising) remains aspirational for the entire sector.

The gap between current maturity and the level needed to support the energy transition is significant. Net zero requires data-driven decisions about network investment, flexibility procurement, EV charging infrastructure, and heat pump deployment. These decisions depend on data that is accurate, timely, interoperable, and accessible. A sector operating at Level 2-3 maturity cannot reliably provide this.

Root causes of the maturity gap

Several structural factors explain why maturity is low despite years of regulatory attention. First, data has historically been a byproduct of network operations, not a strategic asset. Network engineers collected data to operate the network, not to publish or share it. The skills, processes, and systems designed for operational use do not translate directly into data governance capabilities.

Second, the regulatory framework has been fragmented. Data obligations are scattered across multiple codes, licence conditions, and guidance documents. No single person or team in most organisations has visibility of all their data obligations, let alone the capability to manage compliance holistically.

Third, investment has been inadequate. RIIO-ED2 included digitalisation funding, but much of it was directed at specific technology projects (monitoring equipment, data platforms) rather than the organisational capabilities (people, processes, governance structures) needed to sustain good data management over time. You can buy a data platform in a year; building a data culture takes a decade.

Fourth, there is no meaningful enforcement mechanism for data governance quality. Ofgem can audit compliance with specific licence conditions, but assessing overall governance maturity is subjective. There is no equivalent of the BSC Performance Assurance Framework for data governance more broadly.

Closing the gap

RIIO-3's inclusion of explicit data quality metrics as regulated outputs is the most promising development. If network companies are assessed and rewarded based on measurable data quality improvements, the incentive structure shifts from compliance to excellence. The Energy Data Taskforce's recommendations also point toward a sector-wide data catalogue and common metadata standards, which would address the findability dimension of FAIR.

But technology and metrics alone will not close the gap. The hardest part is cultural change: convincing network engineers that data is as important as cables, convincing boards that data governance is a strategic capability, and convincing regulators that maturity assessments need teeth. Without all three, the maturity gap will persist even as the technology improves.

Sections 8.1 to 8.3 assume a world where each organisation publishes its own data on its own portal and is judged on how well it does so. That world is changing. GB energy is moving from publish-your-own-portal towards shared infrastructure that many parties contribute to and draw from, and control over data is shifting with it.

The Data Sharing Infrastructure (DSI) is the clearest example. Rather than a single database, it is a set of common rules and connective plumbing that lets datasets be discovered and exchanged across organisations under agreed governance. Following Ofgem's governance decision of March 2025, NESO coordinates its delivery to 2028, with early capability piloted inside the Virtual Energy System programme. There is no fixed public launch date; the governance was settled first, on purpose.

Three things people confuse: DSI, repository and portal

The DSI is easy to conflate with two other pieces of shared infrastructure that do different jobs and have different owners. Keeping them apart is the point of this section.

The DSI is governance and connective plumbing for organisation-to-organisation data sharing, coordinated by NESO. It does not hold the data itself; it makes distributed datasets findable and exchangeable under common rules.

The Elexon Smart Data Repository is a specific store, launching in autumn 2026 out of the DESNZ and Ofgem scoping exercise, built to hold smart metering and related data for approved uses. Elexon owns and runs it, and it holds data rather than only pointing to it.

The NESO Data Portal is NESO's own open-data publishing platform: the place NESO puts its system, market and forecasting datasets for anyone to download. It is a publisher of one organisation's data, not a cross-industry sharing layer.

Read together, the three show the direction of travel. A single publisher's portal (the NESO Data Portal) is the old model done well; a shared store (the Smart Data Repository) and a shared exchange fabric (the DSI) are the new model, and both move control away from the individual data holder towards jointly governed infrastructure.