This page explains how we identify potential breaches, who we contact, and how we communicate and follow up with DIP Users.

What counts as a breach

A breach is when a DIP User does not meet one or more of its obligations under the DIP Rules or related requirements. Examples may include:

  • not sending required data flows, or sending them late
  • sending incorrect or incomplete data
  • not following agreed processes or technical standards
  • breaching security or access requirements

The DIP Manager assesses each potential breach on a case‑by‑case basis, taking into account its severity and impact.

How we identify potential breaches

The DIP Manager uses several reporting methods to identify different types of breaches:

Method What does the report entail?
DIP Performance reporting DIP Performance reporting allows the DIP Manager to see total volumes of messages in ingress and egress. It can be filtered by DIP ID, interface and time.
Migration reporting When there is a significant number of recipient failures or when latency threshold is breached DIP Manager will receive a report with a breakdown of all messages in ingress and egress. This will be for the period of six to seven pm. This contains the number of messages accepted and number of messages rejected as well as what is the reason.
Daily IF 21 reporting DIP Manager receives a daily IF 21 report which has the number of messages in both ingress and egress, grouped by DIP ID. This contains the number of messages rejected at ingress/egress.
DLQ Monitoring DIP Manager receives an automated report with the number of messages in the DIPs dead letter queue (DLQ).

 

Who is contacted when a breach is identified

When a breach is identified, the DIP Manager will contact the relevant DIP User(s), depending on the risk category involved.

A risk category is a high-level grouping that organises similar types of risks into logical themes and shows which user roles are linked to each category.

User Role Risk Category
User Admin Connection and Operation
Certificate Admin Technical
Message Admin Security

How the DIP Manager communicates about issues

Initial request

When a potential non‑compliance is identified, the DIP Manager will ask the relevant DIP User to investigate. The request will include:

  • a description of the issue
  • the expected timeframe for a response (set case by case, based on the severity and urgency of the issue)

DIP User response

The DIP User is expected to reply within the specified timeframe, either by:

  • requesting further clarification, or
  • acknowledging the issue and providing an estimated date for implementing a fix

Follow‑up

If the DIP User does not respond within the stated timeframe, the DIP Manager will send a follow‑up email.

 

If you use a third‑party service provider

If a company uses a DIP Connection Provider (DCP) or another third‑party service, the DIP Manager will engage only with the company, not the service provider. The company is responsible for:

  • managing its commercial relationship with any service providers it uses
  • ensuring that those service providers support the DIP User in meeting their obligations