CoCo1.1.1
reason:
amended for accuracy
change:
added – recommend implementing TLS v1.3 in addition to v1.2 where possible – ie should initially attempt communication via v1.3 and establish a connection via 1.3 where both parties to the interaction support v1.3, but retry using v1.2 if the other party does not support v1.3 (NSCS advise v1.3 is designed to be more secure than previous iterations)
requirement:
must implement at a minimum and must always support Transport Layer Security (TLS) encryption profile 1.2 for all ecosystem communication where a connection is successfully established between both parties using v1.3, they must not fall back to 1.2
CoCo1.1.2
reason:
amended for accuracy
change:
clarifying the requirement applies to all system-system communication
requirement:
must implement Mutual TLS (mTLS) encryption for all system-to-system communication within the ecosystem
CoCo1.1.3
reason:
we had some consultation push-back on requiring this rather than allowing providers to determine the appropriate level of encryption based on their categorisation of the data, and we had questions over whether it applied to backend systems too. We have decided it is too strong a prescription, and it is for data controllers to determine the appropriate level of encryption for data at rest within their systems. We are recommending but not requiring use of this encryption standard for data at rest
change:
added – recommend encryption of data at rest in accordance with industry best practice: recommend implementation of encryption standard AES-256 for data at rest within pension provider/QPDS systems (e.g. view data cached temporarily at a QPDS; pension identifiers stored on a QPDS user account; transaction identifiers/audit logs stored by pension providers/QPDS)
requirement:
removed
CoCo1.2.1
reason:
amended for accuracy
change:
added ‘critical’ to the defects not permitted, and added qualification that ‘medium’ defects will usually be required to be fixed, but we may allow reasonable exceptions. Clarified this relates to connecting infrastructure rather than back-end systems, in response to consultation feedback on scope
requirement:
must undergo an initial IT Health Check carried out by an independent third-party CREST-accredited scheme on interfaces to the ecosystem must cover as a minimum scope the new infrastructure introduced in order to connect to the ecosystem (PDP Security Working Group will verify this scope) must report IT Health Check results to PDP and attend the PDP Security Working Group to present evidence and receive PDP approval must evidence that IT Health Check results either: (a) identify no critical, high or medium defects (minor defects are permissible), or (b) show any critical, high or medium issues identified have been addressed (medium-level defects should be fixed prior to connection, but PDP may allow reasonable exceptions, if a valid case can be made and approved by PDP that the threat can be adequately mitigated through other controls) must evidence a remediation plan, approved by the CREST-accredited IT Health Check assessor, for addressing any minor defects identified within a year, and to have resolved them by the subsequent annual re-test (as per 1.2.2.)
CoCo1.2.2
reason:
acknowledgement of the cost of undergoing IT Health Check: if no infrastructure changes, this will be an unreasonable cost. Amended retention period to align with other required data retention periods on pension providers
change:
added qualification that over time we expect to reduce this. Added ‘critical’ defects not permitted and qualification that PDP may allow reasonable exceptions for medium defects changed retention period to 6 years
requirement: must annually re-take a CREST-accredited IT Health Check, covering at a minimum the infrastructure and services used to connect must ensure any critical, high or medium defects are addressed immediately (PDP may allow reasonable exceptions for medium defects, if the threat can be adequately mitigated through other controls) must keep evidence of all IT Health Checks for 6 years
CoCo2.1.1
reason:
there were indications from a couple of consultation responses that the ACK time was too demanding. In addition, feedback from Origo working with the Alpha providers in test has indicated <1 second is too fast and needs to be <2 seconds
change:
changed response time from <2 seconds from <1. Clarified the SLA – 99.9%
requirement: must acknowledge receipt of find requests by the find interface, by means of ACK (as per technical standards [add reference]) in <2 seconds (99.9% of ACK responses to acknowledge receipt of a find request to be returned in <2 seconds) ACK response time is the time lapse between receiving the find request from the PFS and sending the ACK
CoCo2.1.2
reason:
several consultation responses sought clarification on what %s required change made to clarify that all finds must be completed within 60 seconds, in view of the user experience (finding pensions is designed to be an in-session experience) and also cost (increasing response time would mean increasing the size of the CDA cache and more traffic, increasing costs) PDP’s qualitative research supports this: that most respondents expected the service to deliver pensions information quickly, if not instantaneously
change:
clarified this is an absolute requirement, not % finds SLA
requirement:
must complete responses to find requests, including registering any pension identifiers for positive matches (including both matches made and possible matches; negative responses are not required) with the consent and authorisation service in <60 seconds following sending of the ACK
CoCo2.1.3
reason:
responses to the consultation indicated widespread concern about the view response time. We asked a question directly about the extent to which this might proscribe return of real-time values and force use of static data, uploaded periodically to a central data lake at the ISP, rather than allowing use of APIs to retrieve more up-to-date values from administration platforms. Most respondents who responded directly to this question indicated <2 seconds would be too fast and would make return of real-time values impossible, and require a data lake architectural solution and static values – and some indicated it was too fast, even regardless of whether the values were real-time or static. 19 respondents said <2 seconds was too demanding, while only 2 supported it. Respondents gave a range of suggestions for reasonable view response times, including 5 seconds, 10 seconds, 15 seconds and 20. The average suggested time (both median and mode) was 10 seconds: Changed response time from <2 seconds to <10 seconds.
change:
recommend that, where static values are bulk-uploaded and stored locally in a central data lake solution, rather than calculated real-time via APIs to distributed data systems, the target for view request responses should be 2 seconds.
requirement:
must respond to view requests In <10 seconds (99.9% of view data payloads retrieved from systems and returned to the dashboard that issued the view request returned in <10 seconds) view request response time is the time lapse between receipt of a dashboard view request and return of the view data payload (this includes the authorisation call to the consent and authorisation service to check authorisation of the view request) view response time applies regardless of the view data payload – i.e. whether the values are returned immediately in response to the view request, or whether a 3/10 working day calculation period (as per legislation) applies – if the pension provider uses the permitted 3/10 working day period to calculate the values, the initial view response (comprising of the administrative data and signpost data) must still be <10 seconds
CoCo2.1.4
reason:
PFS design does not currently include queueing find requests
change:
removed erroneous reference to processing backlog; added requirement that no data be lost following AC
requirement:
must restore service within 2 hours in the event of an endpoint outage, without loss of data ACKed before the outage
CoCo2.1.5
reason:
there was some push-back on the service availability requirement in consultation responses. Many respondents sought clarity on whether this was 24/7 or business hours only, with 4 respondents indicating that whilst reasonable for core hours when dashboards may be expected to be used, such a requirement would be unreasonable if 24/7 and there should be a more relaxed SLA overnight, to allow for routine patching windows, database back-up, etc. There were also questions about the availability both of the central digital architecture, and of the PDP helpdesk to assist with identifying where outages are caused by the data provider’s interface vs the central digital architecture and to support resolution of service
pensions dashboards are a digital service, and if the requirement was core hours rather than 24/7, this could have a significant impact on the user experience and the service reputation if users attempt to use dashboards outside of the core hours (since if a data provider’s endpoint is down, find requests/view requests will not be serviced) and we believe 99.5% 24/7 is commensurate with other digital services. CDA will be available 99.5% 24/7, and data providers need to match this – as a digital service, should be available 24/7, not business hours only
overall, more respondents (9) who directly responded to the question about the reasonableness of the proposed requirements indicated that the proposed service levels were reasonable than those who indicated that the proposed requirements were not reasonable/too demanding (4), and most respondents (12) who directly answered the question about whether any of the proposed requirements would pose specific problems said they did not see any specific issues
change:
clarified that this applies to data providers rather than QPDS. Clarified that the requirement is 99.5% 24/7. Removed erroneous reference to unscheduled downtime – 99.5% is required regardless of scheduling, 0.5% downtime includes both scheduled and unscheduled removed erroneous reference to best endeavours out of hours – hours are irrelevant, the requirement is 24/7
CoCo2.2.2
reason:
requirement now redundant, final regulations require providers to de-register the pension identifier as soon as possible if the possible match is resolved not to be a match
change:
guidance only – in the event of no match being made against a find request received (including when a possible match is resolved not to be a match, or is not resolved), the find request should be deleted – or, alternatively, data providers may investigate whether they can store a hash of some of the details used in the search so that when a subsequent search is initiated by the same user within a given period, a repeat search against a known no-match is not needed
CoCo2.2.3
reason:
requirement now redundant, final regulations require the pension provider to re-register the PeI as soon as possible where the member ceases to be a relevant member
change:
guidance only – pension provider matching processes should support multiple concurrent possible matches: matching may identify multiple potential matches for different users for the same pension
CoCo2.2.4
reason:
if the PAT is not expired, the pension provider will not be able to de-register – so PDP needs to know so that we can de-register
change:
added requirement to notify PDP if pension identifier de-registration is not possible, so that PDP can manually de-register
CoCo2.2.1
reason:
clarified that scheduled outages for maintenance still count towards 0.5% allowed downtime
change:
added – wherever possible patches and upgrades should be applied without any service outage, but reasonable exceptions where updates require a short outage to re-boot to apply upgrades may be allowed, with advance notification (such outages nonetheless count towards the 0.5% downtime permissible)
CoCo2.2.5
reason:
moved to guidance, since we don’t have specific requirements here – we are leaving it to providers to judge when to notify us of issues, rather than attempting to set out precise details of exactly when and concerning what providers should notify us of, which would likely miss things – it is preferable to leave it high-level and to provider discretion
change:
moved to guidance rather than specific requirement – should notify PDP of any threats to the performance or security of the ecosystem as soon as they are known and contribute intelligence relating to ecosystem security to the PDP security operating centre, as well as receiving and acting appropriately on any security intelligence received from PDP
CoCo2.2.6
reason:
requirement added to mitigate risk of find requests not being processed without the user’s knowledge, resulting in pensions not being found. PDP may use this information to then notify dashboards users that they may need to re-send find requests if they have/re not sure whether they have a pension with any of the affected providers. Otherwise, the find request will simply have been lost, and there could be pensions missing as a result. Could also be valuable intelligence to pass to regulators (evidence of non-compliance with duties to undertake matching against received find requests)
change:
new requirement
CoCo3.1.1
reason:
consultation respondents queried how routine absences were accounted for
change:
added – recommend sufficient staff are assigned to the required roles to cover routine absences – the PDP Salesforce platform allows the addition of multiple users for a single required role, allowing deputies to act for the required key roles where the primary contact is unavailable
CoCo3.1.2
reason:
new requirement to provide these data items at onboarding
change:
must provide data required to register with PDP (MaPS) as a pension provider: (part) scheme name, customer-facing name(s), dates over which customer-facing name(s) are applicable, regulator-issued registration code, regulator number, regulating body, holder name, holder name view endpoint, and details for the data provider find endpoint, view endpoint, PAT refresh endpoint
CoCo3.1.3
reason:
new requirement to provide these data items at onboarding
change:
must provide data required to register with PDP (MaPS) as a QPDS: regulator-issued registration code, regulator number, dashboard redirect URL, dashboard UMA claims redirect URL
CoCo3.2.1
reason:
added – recommend following ITIL service incident and problem management processes best practice guidance
change:
must have a defined remediation route for service level failures
CoCo3.2.2
reason:
revised to make clearer this pertains to internal issues within a provider
change:
must have internal escalation frameworks and processes and ensure staff know how and to whom internally issues should be escalated and when
CoCo3.2.3
change:
must have a framework for raising issues and monitoring issues to resolution
CoCo3.2.4
reason:
requirement to comply with forensic investigation including mediated access to audit logs was erroneously missing from version consulted on but is needed to support investigation
change:
new requirement to ensure cooperation with investigation
CoCo3.2.5
reason:
If a pension provider must be dis-connected, but was connected via an ISP, PDP cannot disconnect, without also thereby disconnecting all the other clients of that ISP connecting via the same endpoint, putting these other pension providers in breach of their duties – the ISP must disconnect the pension provider
requirement added to ensure ISP does so – to be compliant, the pension provider must then contract with the ISP to provide for its disconnection if instructed
change:
new requirement to ensure ISP doesn’t keep a pension provider connected when it shouldn’t
CoCo3.2.6
change:
moved from onboarding to BAU operational standards
CoCo3.2.7
change:
new requirement to ensure registration data is maintained and kept up to date to account for changes to part-schemes, holdernames etc eg due to mergers and acquisitions