Technical connection: Service acceptance

Overview

Purpose of this step

To allow PDP to assess your approach to technical connection so that it can be authorised and actioned. Your evidence needs to provide the Pensions Dashboards Programme (PDP) with the assurance that:

• your solution is built to PDP’s data standards, technical standards and code of connection
• any known defects do not present significant risks to the ecosystem
• you have identified the relevant steps to move into the production environment
• you have identified the relevant steps to back out of the production environment or reverse changes.

If the evidence provided does not give PDP sufficient assurance of the above criteria, then we may ask for additional information and pause your connection journey.

This guidance explains how to submit your evidence to PDP.

Who completes this step?

• service manager

Read the full list of roles and responsibilities.

Before you begin

Make sure that all the required documentation has been completed. This includes release notes, transition and implementation plans, and a backout plan. You will also need to have decided on your proposed connection date.

What you need to do in this step

You will need to upload 3 documents, each of which demonstrate your compliance with the code of connection (CoCo) sections 3.1.10-3.1.17:

1. Provide release notes – these should provide detail about what code was released in your most recent deployment and any details of known defects.
2. Propose a date when you want the connection to go live
3. Provide your transition and backout plan – this should detail the steps you take to move into and out of the production environment.
4. Provide evidence of internal IT service acceptance – this evidences that you have obtained internal change approval.

You will also need to provide a proposed connection date for your vouching scheme.

Your submission will be reviewed by the PDP technical team.

1. Provide release notes (CoCo 3.1.12)

Your release notes should describe the features being released as part of the product/solution you are using to directly connect to PDP. The release notes are intended solely for PDP’s internal stakeholders and are not intended for end users. The release notes need to refer to your organisation name and their creation date, for example: Release notes - [your organisation name] - [DDMMYY]

The release notes need to include:

• an introduction and brief overview of the release and its purpose
• release contents (high level details of what you will be delivering)
• any other relevant information, such as new functionalities or compatibility considerations
• contact information for the support and release teams (CoCo 3.1.11)

Only the most recent release note is required.

In the same document you should also detail any known, outstanding defects (CoCo 3.1.15). This should include:

• a concise summary of each defect
• impact of each defect (such as on functionality)
• severity of each defect
• risks associated with each defect
• mitigation for each defect
• details of any workarounds and bug fixes
• remediation plans

2. Propose a date when you want the connection to go live (CoCo 3.1.13)

This is the date when you require your vouching pension provider or scheme to be connected to the live environment. In some instances, this date may sometimes need to be changed, for example if the infrastructure is being updated.

3. Provide your transition and backout plan (CoCo 3.1.10, 3.1.14, 3.1.16)

Your transition plan (sometimes referred to as an “implementation plan”) (3.1.10) should list the steps required to move your service into production and to connect to the live environment. Your service transition plan (3.1.16) may be covered as part of your implementation/transition plan.

Your plan should feature detailed runbook steps for the implementation of the service into live, including:

• pre-migration steps
• migration steps
• post-migration steps
• verification steps

It should also include:

• timelines for the detailed steps above
• any identified risks
• contact details of the implementation team

Within the same document, you also need to provide your backout plan (CoCo 3.1.14). Your backout plan needs to specify how to undo the release. This includes uninstalling or disconnecting, as well as reversing process changes.

Your backout plan should include:

• criteria and triggers for backing out of the release
• detailed steps for backing out
• tools required
• roles and responsibilities for the backout steps
• timeframes for completing the backout

4. Provide evidence of internal IT service acceptance (CoCo 3.1.17)

You must also upload evidence of internal IT service acceptance. This is also referred to as “Internal IT change management approval”.

Internal IT service acceptance is where your organisation’s IT service/change control team (or equivalent) applies a set of criteria to ensure that the software that you have developed meets your own functionality and quality requirements and is ready to be deployed.

How you do this depends on what tool you use. For instance, if you use a service management tool such as ServiceNow, you can provide a screenshot that shows that this process has been completed.

Format of internal IT service acceptance

The file you upload can be in JPEG, PNG or PDF format and up to 25MB.

5. Submit request

We may ask you to provide additional information by updating your submission on the connection portal.

We may ask you to attend the Operational Change Control Board (OCCB) – this generally happens where:

• a high number of defects have been identified
• a high impact defect has been identified
• a high-risk defect has been identified
• we need clarification about your risk mitigation steps
• we need clarification about your implementation steps or timing
• we need clarification about your known issues and workarounds

If necessary, where insufficient information is provided or where issues have not yet been addressed adequately, we may pause your connection to protect the ecosystem.

If the date requested for connection needs to be amended, the change and release manager will contact you to discuss this.

What happens next

PDP will then email your primary business contact for details of your live endpoints.

How long will it take?

You should get a response from PDP by email within 10 working days. If you have not heard from us by then, let us know via support.

All emails from PDP will come from [email protected]. Check your junk or spam folder and ask your IT department to add this email to an allow list of addresses.

Support

Changelog

Last updated:12/03/2025