Expectations for Data Holders during extended Register outage

[CDR-Register-Stream]

Expectations for Data Holders obligations during extended Register outage needs to be defined.

Data Holders will need to identify when the CDR is no longer trusted during an extended Register outage and the following questions will need to be answered:

1. When does disclosure of CDR data stop?
2. When should requests for consent authorisations be denied?
3. When should requests for consent withdrawal be denied?

This issue has been raised to prompt discussion and document the analysis prior to documentation updates

[ryderwj]

It's difficult to consider the scenario of a long term registry outage that is not coupled with some out of band communication to participants - certainly to data holders.

Im assuming the definition of registry outage means the inability of a DH to reach the Registry and refresh their cache whether this is due to outage on the registry itself, a technical problem at the DH or an issue anywhere in between.

Is it appropriate to have an automated, time-based approach to this situation or is it better to require each DH to have the ability to globally disable their authorisation and data sharing in response to a structured decision and notification process of which time since last registry access is only one factor.

This same capability would then be available to be applied to other events and not just limited to the registry outage scenario. This could include incidents/outages localised to a DH as well as the overall ecosystem.

In response to the questions, Im thinking it might be easier to treat these hopefully unlikely scenarios as all or nothing situations and disable data sharing and all consent operations.

Related to this, if the registry had cause to rapidly disable sharing across the entire ecosystem, what is the planned mechanism for this - would a global update of all participant statuses to "suspend" occur?

Also, would like to confirm that when sharing is disabled in this way, what category from a rules perspective should any related refusals be reported under. My assumption at the moment is 4.7.(1).b.ii.(a) applies.

[perlboy]

Consideration needs to be given for a failure within ACCC Register infrastructure having a cascading and long lasting impact on Recipients who have invested significant amounts of capital to enter the scheme in the first place.

If the plan is that, if the Register is down, sharing should be halted by Holders what recourse do Recipients have with respect to recouping the capital outlay they have made? This thread appears to expose the potential of a bad actor to cause a significant and long lasting impact on data recipients through a coordinated denial of service conducted on the ACCC Register.

I would suggest instead that the ACCC defines a "backup" method of changes in Recipient statuses, for instance, a GPG signed email that can be sent and verified out of band, such that, in the event of an extended outage, operations can continue for dynamic client registrations already established between Holder and Recipients and, if necessary, since accreditation suspension seems like a relatively low frequency event, manual processing conducted by Holders using the backup method.

By taking the latter approach the ACCC ensures that a Register outage does not permanently and irreversibly impact Data Recipients existing businesses.

[CDR-Register-Stream]

Thankyou @ryderwj and @perlboy for your input.

The ACCC has performed significant review on this topic and has the following position:

---

Data Holders (DH) are to trust the Local Cache in the event of an outage to the Register indefinitely until advised by the ACCC

The ACCC will be relying on out of band communications to advise participants on the status of the platform and therefore what data sharing and consent obligations they have.

---

The details of this process and the types of requests the ACCC will make of Data Holders will need to be provided so Data Holders can cater for these scenarios in their own processes

[commbankoss]

The details of this process and the types of requests the ACCC will make of Data Holders will need to be provided so Data Holders can cater for these scenarios in their own processes

Without the additional details mentioned above, Commonwealth Bank cannot guarantee that our systems and processes will be able to address ACCC requests.

We therefore request this issue be labelled Urgent, and that further details be provided urgently.