This page displays the DIP Risk Register, a list of potential issues that could cause any DIP Participant or the DIP as a whole to become non-compliant with the DIP Rules, along with how each risk is assessed and managed.
What is the Risk Regsiter
The DIP Manager is responsible for maintaining a DIP Risk Register to record any potential issues that could cause a DIP Participant, or the DIP to become non-compliant with the DIP Rules.
The DIP Manager reviews the entire DIP Risk Register quarterley, reviews individual risks on their scheduled dates, and updates the DCAB on the results after each full review.
Risk Register - updated January 2026
[No dates?, Which is the latest one? Is there a risk score? What are the risk IDs? priority (most important) or oldest]
| Risk ID | Category | Title | Description | Issue | Mitigations | Obligation | References |
| 1 | Connection and Operation | Incomplete or Failed DIP Onboarding | Risk that a DIP Applicant does not complete onboarded activities successfully and/or in a timely manner.
Code Bodies do not inform the DIP Manager of Qualification completion. |
Prevents access to DIP, halting participation.
Affects code qualification. Delay migration of Metering System IDs (MSIDs) |
Structured onboarding processes with guidance provided to DIP Users.
Functional and non-functional checks completed in coordination with Code Bodies ahead of promotion to production. DIP drop-in session fortnightly offered to DIP Applicants during migration |
a) DIP Applicants agree to comply with DIP Rules.
b) DIP User using a Certificate Admin from a third party (DCP or other) are responsible for ensuring that the third part Certificate Admin complies with all relevant aspects of Digital Certificate management as set out in the DIP Rules. c) DIP Users must sign Access Agreement ahead of onboarding. d) DIP User must complete relevant testing ahead of onboarding and provide evidence. e) DIP Users must demonstrate ISMS compliance as part of onboarding |
DSD002 Section |
| 2 | Security | Certificate Management | The Risk that a Digital Certificate is created, maintained or revoked incorrectly.
Risk that a Digital Certificate is compromised due to poor DIP User processes. |
Potential data breach, denial of service or malformed/fraudulent messages sent. | Extensive guidance to support certificate creation.
DIP Manager has the capability to revoke of certificates. DIP User controls on both GlobalSign Atlas portal and DIP Portal.
Separate Certificates across different environments, introduction of API Stop/Start functionality |
a) a DIP User will have appropriate certificate setup depending on their organisation setup.
b) a DIP User will revoke certificates when required to c) DIP User will be responsible for the generation of TLS keys and CSRs used by their Message service interface d) DIP Users need to submit a CSR which is complicit with the DIP Rules e) DIP Users are responsible for managing and securing their certificates f) DIP Users need to verify domains |
DSD002 Annex 2 Section 6
DSD002 Annex 3 DIP-PKI Policy |
| 3 | Security | Private Key Management | Risk of Private Key compromised by DIP User or DCP.
Risk that digital signatures are not created correctly. |
Identity spoofing, fraudulent/malformed messages sent, undelivered messages | DIP Manager has the capability to revoke of certificates, introduction of API Stop/Start functionality | a) DIP Users shall follow the DIP-PKI policy
b) DIP Users bear responsibility for the use and security of the Private Key associated with a Digital Certificate. c) a DIP User using a DCP is ultimately responsible for ensuring the DCP complies with the DIP-PKI Policy. d) DIP Users must ensure that the security of the private key is protected appropriately with a valid form of protection. e) DIP Users, who are natural persons, must be authenticated to their cryptographic module before the activation of the Private Key. |
DSD002 Annex 2 Section 4
DSD002 Annex 2 Section 10 DSD002 Annex 3 Section 5.9 DSD002 Annex 3 Section 6.9 |
| 4 | Security | Cybersecurity | The Risk that a DIP Users system introduces malware or causes a cyber security incident.
Risk of cyberattack on DIP infrastructure. |
Platform disruption, data exposure, fraudulent/malformed messages sent, undelivered messages | DIP Users have ISO27001 certification or equivalent, Checks conducted by DIP Manager at onboarding, introduction of API Stop/Start functionality Self-attestation, annual Code of Connection SAD, audit requirements. | a) DIP Users shall undertake Penetration Testing and vulnerability management testing routinely in accordance with Good Industry Practice and ISO 27001 requirements’) DIP Users shall maintain a Cyber Incident response plan which may be part of a crisis management plan, and which may also be comprised in wider organisational plan.
b) DIP Users need to submit their Cyber Incident Plan to the DIP Manager as part of the DIP Managers assurance activity. c) DIP User shall periodically test their Cyber Incident response plans (where relevant in line with the ISO 27001 requirements). The results of such tests shall be retained for a minimum of 5 years and shall be presented to the DIP Manager when required. d) DIP User needs to demonstrate compliance with ISMS requirements at DIP Onboarding and as part of assurance and audit regimes. e) DIP Users when changing ISMS policies from what is presented in documentation need to provide at least one months’ notice and a proposal for how they shall meet the compliance |
DSD002 Section 3.2.1, 3.2.2
DSD002 Section 6.2 DSD002 Annex 1 Section 1.1.1 (e)(f) DSD006 Section 2.2 |
| 5 | Security | Data Management | Risk that a DIP User does not handle data correctly.
Risk that a DIP User’s system causes a data breach |
ICO fines, reputational damage | Ofgem’s Data Best Practice Guidance, introduction of API Stop/Start functionality | a) DIP Users shall adhere to the Authority’s ‘Data Best Practice Guidance’.
b) DIP Users need to provide information relating to how DIP Users are complying with DIP data rules c) DIP Users does not have data protection policies and controls under ISMS practices d) DIP Users when changing data protection policies from what is presented in documentation need to provide at least one months’ notice and a proposal for how they shall meet the compliance |
DSD002 Section 3.2.1, 3.2.2
DSD002 Annex 1 Section 1.1.1 (e)(f) DSD006 Section 2.3 DSD006 Section 3.4 |
| 6 | Technical | DIP Message delivery/latency | Risk of DIP message loss or corruption in transit.
Risk of message not being sent |
Settlement and operational errors due to messages not being processed in prescribed times or at all. | TLS encryption, digital signatures, message validation and replay APIs | a) DIP Users need to encode JSON messages using UTF-8 format.
b) DIP User will need to send messages to channel specific endpoints c) DIP Users’ systems, depending on role need to provide an asynchronous response in suitable time. d) DIP Users’ systems, depending on role need to provide an initial synchronous response in suitable time. e) On receipt of message a DIP User should endeavour to validate the message contents as much as feasibly possible and relay all validation errors back to the Sender f) DIP Users will need to be aware they are receiving obfuscated data on specific channels g) DIP Users need to apply message signatures for most messages in order to send message into DIP. h) DIP Users on receipt of a message, need to verify message signatures i) DIP Users are expected to adopt a retry with exponential back off (up to a configurable maximum wait time) if there is a failure in connecting to the DIP. |
DSD002 Annex 2 Section 7
DSD002 Annex 2 Section 9 DSD002 Annex 2 Section 11.4.2 |
| 7 | Technical | DIP Users using API/Webhooks | Risk of APIs and webhooks not working correctly.
Risk that DIP Users do not use APIs or webhooks correctly |
Messaging downtime or duplication | API key rotation, retry logic, exponential back-off, monitoring | a) DIP Users need to send messages to valid Api.
b) DIP User when sending a message will be responsible for message construction, message addressing, message signing, API Call, API response, back off and retry and managing multiple connections. c) DIP Users when receiving a message will need to validate this in two forms synchronous and asynchronous. d) DIP Users will utilise the replay and re-queue API appropriately e) DIP User will configure Webhooks suitably |
DSD002 Annex 2 Sections 9.1 & 9.6 |
| 8 | Technical | DIP User System Performance | Risk of DIP infrastructure overload or underperformance during peak volumes as a result of DIP User systems.
The Risk that DIP User systems cannot handle DIP messages during peak volumes. |
Delayed or dropped messages, potential processing failures if messages fail to deliver after retries | Performance benchmarking, DIP scalability planning, DIP Performance reports. | a) DIP Users’ systems shall have the capacity to process messages according to the following volumes:
i) Average daily volume of 66,000 messages/day ii) Peak daily volume of 300,000 messages/day iii) Average hourly volume of 2,750 messages/hour iv) Peak hourly volume of 35,000 messages/hour v) Annual volume of 24,000,000 messages/year. b) DIP Users need to alert DIP Manager when their system will be unavailable. c) DIP Users shall not plan routine outages during the period where the Registration service is processing secured active messages d) All DIP User systems (excluding for the handling of Excludes IF-021) shall provide an initial synchronous response to a message within the following timeframes: i) up to average hourly volume, mean response time of 2s or less ii) up to average hourly volume, 90th percentile response time of 4s or less iii) from average hourly to peak hourly volume, mean response time of 5s or less iv) from average hourly to peak hourly volume, 90th percentile response time of 8s or less. e) All DIP Users’ systems (except those stated in sections 11.4.3 and 11.4.4 below) shall provide an asynchronous response (Level 4 validation) to a message within the following timeframes: i) up to average hourly volume, mean response time of 6s or less; ii) up to average hourly volume, 90th percentile response time of 12s or less; iii) from average hourly to peak hourly volume, mean response time of 10s or less; iv) from average hourly to peak hourly volume, 90th percentile response time of 16s or less. Risk of DIP infrastructure overload or underperformance during peak volumes. The Risk that DIP User systems cannot handle DIP messages during peak volumes. |
DSD002 Annex 2 Section 11.3 11.4, 9.8.1, 8.13 |
| 9 | Financial | Late/Failed Payments by DIP Payees | Risk that DIP Payees do not pay | Cash flow issues, emergency funding requirements | Late payment default shares, bad debt recovery clauses, credit monitoring | a) DIP Payees need to pay for DIP Costs.
b) Any costs associated with the release of DIP Manager Data may be recoverable from the DIP User requesting that data. c) Any costs associated with Change Requests will be recovered by DIP Payees |
DSD005 Section 4.5
DSD005 Section 4.9 DSD004 Section 3.3 |
| 10 | Connection and Operation | Incorrect DIP Off-Boarding | Risk that a DIP User is off boarded incorrectly.
Risk that a DIP User is suspended incorrectly. |
Loss of service for DIP User | Structured offboarding processes, coordination with Code Bodies, communication with DIP User | a) DIP User does not inform DIP Manager of date in the case of voluntary off boarding.
b) DIP User in all cases of offboarding will need to pay of any remaining balance. |
DSD002 Section 3
DSD002 Section 4 |
| 11 | Connection and Operation | Supplier of Last Resort, Special Administration Regime, and Trade Sales | Risk that the DIP manager does not route DIP messages from a previous Supplier to the SoLR | Messages missed by SoLR, industry disorganisation | Structured SoLR processes, coordination with Suppliers and Authority | a) In the case of a Trade Sale DIP User needs to alert DIP Manager as soon as possible to coordinate with Authority and Code Bodies | DSD002 Section 4
DSD002 Section 5 |
How to submit a potential risk for inclusion in the register
The DIP Manager shall issue guidance on how the Risk Register shall be compiled, shared and how stakeholders (including DIP Participants) may submit potential risks for inclusion.