A data holder must share required data in response to a valid request that it receives. Subrules 2.5(1), 3.5(1) and 4.7(1) of the CDR Rules provide that a data holder may refuse to disclose data in response to such requests under certain circumstances.
Rules 2.5(2), 3.5(2) and 4.7(3) of the CDR Rules require that a data holder must inform the requester, CDR consumer, or accredited person of such a refusal in accordance with the data standards. The data standards enable data holders to provide error codes to indicate the reason that data has not been disclosed.
The table below sets out the CDR Rules a data holder may rely upon to refuse to disclose data, and the corresponding HTTP error codes as set out in the Standards.
Circumstance |
CDR Rule |
HTTP error code |
Requests received may cause physical, psychological, or financial harm or abuse |
3.5(1)(a), 4.7(1)(a) |
403 Forbidden |
Requests received relate to an account that is blocked or suspended |
3.5(1)(aa), 4.7(1)(c) |
404 Not Found 422 Unprocessable Entity |
Requests received would adversely impact the security, integrity or stability to the Register of Accredited Persons or the data holder's ICT systems (for example, during a potential distributed denial of service or equivalent form of attack) |
2.5(1), 3.5(1)(b), 4.7(1)(b) |
429 Too Many Requests |
Requests received exceed the service level thresholds in the Non-Functional Requirements section of the Standards |
2.5(1), 3.5(1)(b), 4.7(1)(d) |
429 Too Many Requests |
The consumer data request originated from a sanctioned country. |
2.5(1) 4.7(1)(d) |
Data holders should use general error codes for security reasons. It is expected that Data Holders would appropriately instrument their solutions so they can provide relevant information to regulators for audit purposes. |
The return of a 403, 404, 422 and 429 HTTP error code in response to circumstances other than those set out in the above table does not constitute a refusal to disclose data under the CDR Rules.
If a request is not received, or not valid, data holders cannot provide data in response. Therefore, these instances do not constitute a refusal to disclose data, and do not need to be reported under rule 9.4 of the CDR Rules.
More information can be found in published Guidance and various Zendesk articles, such as this and this. A summary table can be found below:
Request attribute |
Data holder obligation |
HTTP code provided to requester |
|
Valid |
Received |
||
Yes |
Yes |
Must disclose required data, except in circumstances set out above. |
200 OK 403 Forbidden 404 Not Found 422 Unprocessable Entity 429 Too Many Requests |
No |
Yes |
Unable to disclose required data in response to an invalid request. |
400 Bad Request 401 Unauthorized 405 Method Not Allowed 406 Not Acceptable 415 Unsupported Media Type |
Yes |
No (due to outages) |
The data holder is unable to disclose required data as the request is not received. |
500 Internal Server Error 503 Service Unavailable 504 Gateway Timeout |
It is not necessarily expected that data holders report on attacks or requests outside the /cds-au/ path of their CDR domain, particularly if the data holder is unable to reasonably identify whether the request is in fact CDR-related. It is also not expected that a data holder will report on requests they failed to respond to due to a scheduled maintenance, unexpected outage or during a period of system instability.
For the avoidance of doubt, data holders are not required to record and report information regarding instances where they have refused to ask for an authorisation (for example for the reasons listed at rule 4.7 of the CDR Rules, such as for the avoidance of harm or abuse).
Comments
0 comments
Please sign in to leave a comment.