Outages reporting: planned, active and future outages
The purpose of the GET Outages API is to communicate future outages. The purpose of the GET Status API is to communicate in-flight outages and when the outage will be rectified.
All planned outages, other than for critical fixes, are expected to be published using the GET Outages API.
It is not intended that the GET Outages API be updated to include unplanned outages after they have occurred.
If a planned outage is to resolve a critical service or security issue, it may occur without notification, to not be considered an 'unavailable' period.
All other periods of outage should be considered as unavailability.
Planned outages should only be commensurate in length and frequency to your other primary digital channels.
The Data Holder should provide advanced notice of outages in a timely manner similar to existing channels.
Use the Get Status API to communicate status during an unplanned outage.
Reporting during outage periods
From a technical perspective, the reporting of a refusal to disclose means that the request is received and is valid but the data holder (for one of a variety of reasons) refuses to provide the requested data.
During a period of system instability or outage the first part of this technical definition may not be met. The initial request may not be received or may not be able to be assessed for validity. In these situations, a refusal to disclose does not need be recorded and does not need to be included in a data holder’s report.
This would, however, be recorded as a period of unavailability under the non-functional requirements in the Data Standards if the outage was unplanned. If the outage was planned and communicated with enough advance notice according to the standards then the calls would not need to recorded either as a period of unavailability or as a refusal to disclose.
Maintaining synchronisation of consents after outages
When the consumer withdraws consent through the DH (Data Holder) dashboard side, the DH is expected to make a reasonable effort to notify the ADR (Accredited Data Recipient) by calling the appropriate ADR revocation endpoint. However the final responsibility for ensuring consents are current rests with the ADR.
If there is an outage on the ADR side, DHs can retry calling using specified back-off patterns. The DH should attempt to communicate the consent withdrawal via the CDR Arrangement Revocation endpoint. Retrying a few seconds upon first failure would be considered a reasonable effort.
It is at the discretion of the DH to determine reasonable effort based on their considerations and compliance obligations. As the DH does not have visibility of ADR maintenance windows and outages, the responsibility for determining whether consent is current does not rest entirely with the DH.
The responsibility for availability and timeliness of the ADR solution is the responsibility of the ADR.
Consent Validation
On restoration of service after an outage, the ADR should validate all active consents to determine whether they have expired, and if still current, whether they have been withdrawn by calling the DH token or token introspection endpoint. If consent is no longer valid, the request to the DH returns an error response communicating to the ADR’s software product that the refresh token is no longer valid. The ADR updates the consent status and ADR consumer dashboard accordingly.
Comments
0 comments
Please sign in to leave a comment.